provider/aws: allow key_pair name to be generated #1751
Conversation
|
Just curious, what is the use case for this? |
|
As a module author, I'd like to be able to create a module that includes a key_pair. This allows my module to be used multiple times in the same account without having to do anything funky like adding a user-specified unique name parameter. |
|
For my money, TF should do this for every AWS resource that must have a unique name. I'd like to enhance the feature down the road so that we can let users define a custom prefix (while retaining the UUID suffix) to help folks who want to visually distinguish stuff. |
|
Interesting. That makes sense. Thanks for the infobits. 👍
|
|
LGTM 🚀 |
I forgot to add `Computed: true` when I made the "key_name" field optional in #1751. This made the behavior: * Name generated in Create and set as ID * Follow up plan (without refresh) * Name got cleared out on Read, causing a bad diff. We can automatically catch bugs like this if we add yet another verification step to our resource acceptance tests -> a post Refresh+Plan that we verify is empty. I left the non-refresh Plan verification in, because it's important that _both_ of these are empty after an Apply.
I forgot to add `Computed: true` when I made the "key_name" field optional in #1751. This made the behavior: * Name generated in Create and set as ID * Follow up plan (without refresh) was nice and empty * During refresh, name gets cleared out on Read, causing a bad diff on subsequent plans We can automatically catch bugs like this if we add yet another verification step to our resource acceptance tests -> a post Refresh+Plan that we verify is empty. I left the non-refresh Plan verification in, because it's important that _both_ of these are empty after an Apply.
phinze
force-pushed
the
f-aws-key-name-gen-name
branch
from
b866129 to
88edca0
Compare
As a module author, I'd like to be able to create a module that includes a key_pair. I don't care about the name, I only know I don't want it to collide with anything else in the account. This allows my module to be used multiple times in the same account without having to do anything funky like adding a user-specified unique name parameter.
phinze
force-pushed
the
f-aws-key-name-gen-name
branch
from
88edca0 to
b99611f
Compare
|
LGTM |
provider/aws: allow key_pair name to be generated
I forgot to add `Computed: true` when I made the "key_name" field optional in #1751. This made the behavior: * Name generated in Create and set as ID * Follow up plan (without refresh) was nice and empty * During refresh, name gets cleared out on Read, causing a bad diff on subsequent plans We can automatically catch bugs like this if we add yet another verification step to our resource acceptance tests -> a post Refresh+Plan that we verify is empty. I left the non-refresh Plan verification in, because it's important that _both_ of these are empty after an Apply.
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
ghost
locked and limited conversation to collaborators
No description provided.