Do not use resourcePrefix alone when assigning names to resources with uniqueness requirements

[glennmusa]

Description

We're generating a resourcePrefix value by default like so:

missionlz/src/bicep/mlz.bicep

Line 465 in 52882f6

param resourcePrefix string = 'mlz-${uniqueId}'

And using that to assign names for certain resources that require uniqueness (things like Log Analytics Workspaces and Storage Accounts) like so:

missionlz/src/bicep/mlz.bicep

Line 643 in 52882f6

param logAnalyticsWorkspaceName string = take('${resourcePrefix}-laws', 63)

This can introduce failed deployments and unwanted behavior when a user specifies their own resourcePrefix value.

We should instead generate some uniqueness and use it for the resource names that require it.

Steps to Reproduce

Steps to reproduce the behavior:

1. Provide a user-supplied value for resourcePrefix like foo
2. Certain items will occasionally fail on redeploy for resources that take longer to clean-up like certain security solutions for Log Analytics Workspaces

Expected behavior

I can provide my own resourcePrefix value to a deployment and re-deploy as often as I want without error.

Actual behavior

Certain items will occasionally fail on redeploy for resources that take longer to clean-up like certain security solutions for Log Analytics Workspaces

Cloud (public, Azure Government, etc.): public

[shawngib]

This should merge with #439 as naming conventions will most likely solve for issues. Also think the issue that originally raised this has a different root cause that this will hide since despite documentation the LA Workspace doesn't require global uniqueness but following a naming convention like -<prefix name/workload>- would solve for. The primary concern is LA naming shouldn't be randomized since then its usage via portal, queries or coding becomes difficult.

[brooke-hamilton]

Also please take #393 into consideration when addressing this bug.

[brooke-hamilton]

The team recommends a spike on proving the implementation: a resource group that has a storage account that has a unique name based on a user-provided value, but is consistently generated so that idempotency is preserved. #503 is the spike.

[shawngib]

Just wanted to place this here for reference of future need in unique names. Log Analytics workspace does not require it to be globally unique as per this GA announcement in commercial and gov: https://azure.microsoft.com/en-us/updates/general-availability-log-analytics-workspace-name-uniqueness-is-now-per-resource-group/

This may need further investigation as it may not be GA in all clouds.

[brooke-hamilton]

This issue was resolved with #556