Workspace deploy fails because storage account is not unique

[t-young31]

Describe the bug
A clear and concise description of what the bug is.

I've just deployed a workspace and get

mError: \u001b[0m\u001b[0m\u001b[1mcreating Azure Storage Account \"stgws2a73\": storage.AccountsClient#Create: Failure sending request: StatusCode=0 -- Original Error: autorest/azure: Service returned an error. Status=<nil> Code=\"StorageAccountAlreadyTaken\" Message=\"The storage account named stgws2a73 is already taken.

looks like the last 4 chars are maybe not unique enough. Seems odd though if it's ~1/10^6 chance

Steps to reproduce

1. Deploy a workspace
2. Be unlucky!

[marrobi]

Very unlucky - depends how many TRE workspaces have been deployed. Maybe we can add the TRE ID into some of these identifiers.

[RIashfaqahmed]

Very unlucky - depends how many TRE workspaces have been deployed. Maybe we can add the TRE ID into some of these identifiers.

thats a good idea!

[JaimieWi]

Just to mention, we have also come across this issue three times in the last week!

[martinpeck]

FYI this is where we generate that name: https://github.com/microsoft/AzureTRE/blob/main/templates/workspaces/base/terraform/locals.tf#L4

We currently take the last 8 characters from a string that already includes the TRE ID. If we took more than 8 (e.g. like we do for the KV name) then we'd pick up the TRE ID as part of the storage account name. However, we have a limit of 24 characters....but that should still be fine.

[tamirkamara]

The root cause of this is using last 4 chars of a uuid (v4=random) for azure resources that need to be globally unique. The complicated factor is that templates make naming assumptions on resources they reference that were created by a parent template. This is also true for some of our python code mainly around the airlock (but is easier to fix).

We discussed a couple of options to resolve this:

1. Increase the uniqueness level of the chars we use but keep the approach of the template developer making naming assumptions. e.g. use more chars of the uuid string (probably not going to help that much), use a real random string rather than the uuid4, etc.
2. Having a way for the template to get the properties of its parents. The pipeline mechanism has something similar but for a specific use-case which we can consider making more generic.
   A template could generate its own random string as it see fit, which will be saved in cosmos (via rp outputs). A descendant template could then reference the property and the pipeline could replace that before sending the operation to the RP.
   This method will be challenging for situations where we have cross workspace references. Maybe in Airlock review? TBD

[marrobi]

Hit this again today...

Status=<nil> Code=\"StorageAccountAlreadyTaken\" Message=\"The storage account named stgws07e4 is already taken.\"\u001b[0m \u001b[31m│\u001b[0m \u001b[0m \u001b[31m│\u001b[0m \u001b[0m\u001b[0m  with azurerm_storage_account.stg, \u001b[31m│\u001b[0m \u001b[0m  on storage.tf line 1, in resource \"azurerm_storage_account\" \"stg\": \u001b[31m│\u001b[0m \u001b[0m   1: resource \"azurerm_storage_account\" \"stg\" \u001b[4m{\u001b[0m\u001b[0m \u001b[31m│\u001b[0m \u001b[0m \u001b[31m╵\u001b[0m\u001b[0m \u001b[31m╷\u001b[0m\u001b[0m \u001b[31m│\u001b[0m \u001b[0m\u001b[1m\u001b[31mError: \u001b[0m\u001b[0m\u001b[1mcreating Azure Storage Account \"stalimappws07e4\": storage.AccountsClient#Create: Failure sending request: StatusCode=0 -- Original Error: autorest/azure: Service returned an error. Status=<nil> Code=\"StorageAccountAlreadyTaken\" Message=\"The storage account named stalimappws07e4 is already taken.