storage account naming guidance

[colemickens]

This is a general question. Somehow, storage accounts are still required to be globally unique, and still only allowed to be 24 characters long. Meanwhile, there are locations with names that are 20 characters long. Say you are building images, which must be homed to a location, what is suggested as a naming scheme?

I can't think of anything better than finding some hashing function that outputs to 24 chars (...), and feed it a subscription id, location, and "unique name", but those output names are all going to be unreadable and generally nonsensical. Other platforms at least give canonical, short names that can be reliably used for naming in such scenarios.

This must be a wide-spread "issue". What are others doing?

[colemickens]

DigitalOcean, Packet, and IBM Cloud use consistently-four-character names. They and the rest that I've checked (aka GCP/AWS) have neither such incredibly short storage account names, nor do they require global uniqueness.

edit: nice and unique: 2c72dd9fc5d7d7bb68d0156 😞

export AZURE_STORAGE_ACCOUNT_ID="nixos_production"
export AZURE_STORAGE_ACCOUNT_UNIQUE="${AZURE_SUBSCRIPTION_ID}${AZURE_LOCATION}${AZURE_STORAGE_ACCOUNT_ID}${AZURE_REPLICA}"
export AZURE_STORAGE_ACCOUNT_NAME="$(echo "${AZURE_STORAGE_ACCOUNT_UNIQUE}" | sha512sum | cut -c1-23)"```

[zikalino]

I think this discussion should not only include storage account names, there are other Azure resources that require names to be globally unique.

I am for instance concerned about examples, if you run examples that require unique name out of the box, most likely it will fail.

[colemickens]

Here's the thing, I (feel like I) shouldn't have to do any of this anyway:

Managed disks takes care of storage accounts under the scenes... and yet... it can't replicate a blob from another location, and I still can't make images public across subscriptions. So instead, I have to do this all myself, maintain the scripts, and distribute them to users so they can then replicate blobs and construct their own images in their subscriptions...

[azureuser@xxnixos-22711:~/code/nixpkgs/nixos/maintainers/scripts/azure/v2]$ cat * | wc -l
139

[zikalino]

@colemickens regarding sharing images across subscriptions, you could use Shared Image Gallery az sig. will that help you?

[colemickens]

Not unless they can be made public, no.

…

On Thu, Jul 25, 2019, 08:36 Zim Kalinowski ***@***.***> wrote: @colemickens <https://github.com/colemickens> regarding sharing images across subscriptions, you could use Shared Image Gallery *az sig*. will that help you? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10041?email_source=notifications&email_token=AACP25CBQHFUVVURML3KELTQBFCYVA5CNFSM4IGVVEYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2YQFNI#issuecomment-514917045>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACP25G2WBQTYORJ4TNEXXLQBFCYVANCNFSM4IGVVEYA> .

[colemickens]

Just allowing MD creation from arbitrary blobs would cut out a lot of frustration. Storage accounts are a nightmare and there's no reason I should need to ask end users go through the hassle of managing storage accounts just to be able to create a MD that ends up replicating the blob transparently anyway. Typing it out makes me a feel a bit crazy. I have to go through all of the trouble of scripting naming and creating a storage account and container, just to replicate a blob, just to create an MD and have the platform replicate the blob again, at which point, the storage account is entirely unneeded again. Such a headache for what should be so simple.

…

On Thu, Jul 25, 2019, 21:25 Cole Mickens ***@***.***> wrote: Not unless they can be made public, no. On Thu, Jul 25, 2019, 08:36 Zim Kalinowski ***@***.***> wrote: > @colemickens <https://github.com/colemickens> regarding sharing images > across subscriptions, you could use Shared Image Gallery *az sig*. will > that help you? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > < #10041?email_source=notifications&email_token=AACP25CBQHFUVVURML3KELTQBFCYVA5CNFSM4IGVVEYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2YQFNI#issuecomment-514917045 >, > or mute the thread > < https://github.com/notifications/unsubscribe-auth/AACP25G2WBQTYORJ4TNEXXLQBFCYVANCNFSM4IGVVEYA > > . > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#10041?email_source=notifications&email_token=AACP25GROXMV7VMFF3ZKPJLQBH4ZJA5CNFSM4IGVVEYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD22QS6Q#issuecomment-515180922>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACP25DQNOKVTML45RJEJRLQBH4ZJANCNFSM4IGVVEYA> .

[colemickens]

It actually appears that Managed Disks + SIG might support exactly what I need to avoid managing storage accounts myself, but there's further clarification needed. See: #10192

[colemickens]

Note: SIG names also have to be unique... At least it's only subscription-wide, I guess, instead of globally like storage accounts. No dashes in gallery names either.

[yonzhan]

@colemickens was your issue resolved?

[jiasli]

I think the limitation on Storage Account name is out of the scope of Azure CLI.

The reason why it has to be globally unique is because the name is used as part of the domain name http://mystorageaccount.blob.core.windows.net to identity the Storage Account.

I checked the feedback forum and did see this post: Increase Storage Account Name Length from Max of 24 Characters. You may vote on this post to get Storage team noticed. Thank you for your understanding.