Update storage account naming convention to use subscription IDs as a unique string seed #571
+32
−11
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This change adds to the implementation from #558 to use the relative subscription ID as a uniqueString() seed to reduce likelihood of storage account collisions.
While not a full proof solution to unqiueness, since Subscription IDs are GUIDs this should generate a hash unique to the deployment subscriptions and prevent naming collisions with deployments to other subscriptions while preserving a redeployment into the same subscription + resourcePrefix and resourceSuffix pair.
It's likely that multiple users deploying into the same subscriptions will collaborate.
It's unlikely that if I pull MissionLZ from the wild I'll have any idea of what other users around the world have named their
resourcePrefix
andresourceSuffix
.Today
Today, in the event someone picks a "unique"
resourcePrefix
and "unique"resourceSuffix
pair that's already been used, when the storage account name is calculated they'll get a storage account name collision:missionlz/src/bicep/mlz.bicep
Line 477 in d2441cb
Proposed changes
This change proposes passing the relative subscription ID for the hub/spoke that the storage account is being created within as another seed for determining the
uniqueString()
hash:First, it creates the token for replacement
unique_storage_token
:missionlz/src/bicep/mlz.bicep
Line 482 in e5fbc84
Then, each hub/spoke generates the name with token replacement:
missionlz/src/bicep/mlz.bicep
Lines 492 to 494 in e5fbc84
Issue reference
The issue this PR will close: #556
Checklist
Please make sure you've completed the relevant tasks for this PR out of the following list: