core: name_prefix names now start with a timestamp #8249
Conversation
|
Hi @glasser! I definitely see the purpose of this, but think we might be best off making the second couple of digits incrementing within a second so that things always sort correctly. We'll discuss internally and take this one forward shortly. Thanks for the PR! |
|
Sure, I can easily make it go out to nanoseconds instead of seconds. Or if that's not good enough, just have a "counter" section too. |
|
Agreed that we should make the granularity more fine-grained than second. I don't think there is any reason we need to stick exactly to the previous format as long as we don't introduce any new "weird" characters (stick to ASCII). So introducing a couple/few more characters that are nanoseconds sounds good to me. |
|
Some underlying resources have name length limits, so I wouldn't want to break people who have already shrunk their prefixes to fit. But it's easy to just shrink the random part. |
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.
glasser
force-pushed
the
glasser/name-prefix-timestamp
branch
from
6c11268 to
4ad825f
Compare
|
Updated to include nanoseconds and only 3 random characters. The test now verifies the ordering property. |
The timestamp prefix added in hashicorp#8249 was removed in hashicorp#10152 to ensure that returned IDs really are properly ordered. However, this meant that IDs were no longer ordered over multiple invocations of terraform, which was the main motivation for adding the timestamp in the first place. This commit does a hybrid: timestamp-plus-incrementing-counter instead of just incrementing counter or timestamp-plus-random.
The timestamp prefix added in hashicorp#8249 was removed in hashicorp#10152 to ensure that returned IDs really are properly ordered. However, this meant that IDs were no longer ordered over multiple invocations of terraform, which was the main motivation for adding the timestamp in the first place. This commit does a hybrid: timestamp-plus-incrementing-counter instead of just incrementing counter or timestamp-plus-random.
The timestamp prefix added in hashicorp#8249 was removed in hashicorp#10152 to ensure that returned IDs really are properly ordered. However, this meant that IDs were no longer ordered over multiple invocations of terraform, which was the main motivation for adding the timestamp in the first place. This commit does a hybrid: timestamp-plus-incrementing-counter instead of just incrementing counter or timestamp-plus-random.
The timestamp prefix added in hashicorp#8249 was removed in hashicorp#10152 to ensure that returned IDs really are properly ordered. However, this meant that IDs were no longer ordered over multiple invocations of terraform, which was the main motivation for adding the timestamp in the first place. This commit does a hybrid: timestamp-plus-incrementing-counter instead of just incrementing counter or timestamp-plus-random.
The timestamp prefix added in hashicorp#8249 was removed in hashicorp#10152 to ensure that returned IDs really are properly ordered. However, this meant that IDs were no longer ordered over multiple invocations of terraform, which was the main motivation for adding the timestamp in the first place. This commit does a hybrid: timestamp-plus-incrementing-counter instead of just incrementing counter or timestamp-plus-random.
The timestamp prefix added in hashicorp#8249 was removed in hashicorp#10152 to ensure that returned IDs really are properly ordered. However, this meant that IDs were no longer ordered over multiple invocations of terraform, which was the main motivation for adding the timestamp in the first place. This commit does a hybrid: timestamp-plus-incrementing-counter instead of just incrementing counter or timestamp-plus-random.
|
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
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 #8143.