core: names produced via name_prefix should start with a timestamp #8143
Labels
Comments
|
I agree with this, if you can make a PR that'd be lovely. |
glasser
added a commit
to meteor/terraform
that referenced
this issue
Aug 17, 2016
This means that two resources created by the same rule during different seconds will get names which sort in the order they are created. The rest of the ID is still random base32 characters; we no longer set the bit values that denote UUIDv4. The length of the ID returned by PrefixedUniqueId is not changed by this commit. Fixes hashicorp#8143.
|
@mitchellh Done, #8249. |
glasser
added a commit
to meteor/terraform
that referenced
this issue
Aug 17, 2016
This means that two resources created by the same rule will get names which sort in the order they are created. The rest of the ID is still random base32 characters; we no longer set the bit values that denote UUIDv4. The length of the ID returned by PrefixedUniqueId is not changed by this commit; that way we don't break any resources where the underlying resource has a name length limit. Fixes hashicorp#8143.
|
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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This looks similar to #494 but is not the same.
Many resources have a
name_prefixattribute which usesresource.PrefixedUniqueIdto generate random names for their resources. This function adds 26 random base32 characters after the prefix.This works really well. But because the varying part is truly random, it's difficult (when, eg, looking at a list of ASGs in the EC2 console) to know which one is the "new one" and which one is the "old one".
I propose that the varying string returned by
resource.PrefixedUniqueIdshould begin with a UTC timestamp like 20160811105022 before a shorter random portion. This is only calculated when a new ID is required (it doesn't present ignore_changes issues like in #494). This should ensure that in most practical situations, you can tell which resource is "new" vs "old" just by sorting their names.I don't think there's real backwards compatibility concerns here, as long as the lengths are the same. I assume that the names generated here are rarely shown to end users of your infrastructure so it's unlikely to reveal secrets.
Happy to send a PR for this if it would be accepted.
The text was updated successfully, but these errors were encountered: