Added missing import.sh files and generate docs

[fantapop]

The docs plugin adds a section to each each resource indicating the support of Import based on the existence of an import.sh example. This file was missing for some resources despite the actual support of the Import action. The missing files are added here and docs are regenerated.

Commit checklist

• Changelog
• Doc gen (make generate)
• Integration test(s)
• Acceptance test(s)
• Example(s)

[fantapop]

@kathancox Most of this wording is built into the framework. I could change the names however and there are a few comments in this PR that serve as documentation. It would be much appreciated if you could take a peek!

[kathancox]

This lgtm, the only question I had (mainly because I'm curious): the .example part of the command what does a user put there? I saw that the issuer command had .my_issuer in comparison to the other command examples, so that stood out!

[fantapop]

This lgtm, the only question I had (mainly because I'm curious): the .example part of the command what does a user put there? I saw that the issuer command had .my_issuer in comparison to the other command examples, so that stood out!

@kathancox this basically like the path of a resource. Usually resource type + resource name. In the example here it would be aws_instance.web:
https://developer.hashicorp.com/terraform/language/resources/syntax#resource-syntax

The naming of the resource in these isn't something we have a strong pattern for at the moment. I've noticed a lot of providers use the name "example" as the second part. Obviously for real configuration, that is not a name that should be used. Mostly what I've done is to try and pick realistic names but given that people use different naming schemes for their resources, it might not be what people use. Also sometimes it's hard to come up with good names. We could also consider trying to match the name in the config examples with the name in the import example. You can see in this one I used:
cockroach_allow_list.vpn for the config example and
cockroach_allow_list.home_office for the import example

I'm not opposed to using "example" for all of them if you think that will help from a documentation perspective.

[kathancox]

This lgtm, the only question I had (mainly because I'm curious): the .example part of the command what does a user put there? I saw that the issuer command had .my_issuer in comparison to the other command examples, so that stood out!

@kathancox this basically like the path of a resource. Usually resource type + resource name. In the example here it would be aws_instance.web: https://developer.hashicorp.com/terraform/language/resources/syntax#resource-syntax

The naming of the resource in these isn't something we have a strong pattern for at the moment. I've noticed a lot of providers use the name "example" as the second part. Obviously for real configuration, that is not a name that should be used. Mostly what I've done is to try and pick realistic names but given that people use different naming schemes for their resources, it might not be what people use. Also sometimes it's hard to come up with good names. We could also consider trying to match the name in the config examples with the name in the import example. You can see in this one I used: cockroach_allow_list.vpn for the config example and cockroach_allow_list.home_office for the import example

I'm not opposed to using "example" for all of them if you think that will help from a documentation perspective.

@fantapop Got it. So, I actually prefer the more descriptive, placeholder resource name e.g., .my_issuer or .home_office compared to .example. I don't think this is a big deal to change though. But, if you're so inclined and can think of more helpful placeholders than "example" it could be worth considering.

Thanks for the explanation there.

[fantapop]

Thanks for your thoughts @kathancox. In that case, I think we should consider doing a sweep for this as part of a later PR. I'd rather just get this one merged for now.