Duplicate URNs caused by truncated Azure resource names

[davemooreuws]

Bug Report

Issue

When deploying to Azure, Nitric can generate resource names that exceed Azure's length limits. To comply, these names are truncated. However, truncation can lead to different resources ending up with identical names, resulting in duplicate URNs and deployment conflicts.

Expected

Each Nitric resource should result in a unique Azure resource name and corresponding URN, even if the original names require truncation.

[tjholm]

This is too broad, needs an issue for each specific instance with its relevant naming restrictions.

[jyecusch]

Since Azure has overly restrictive resource name requirements, such as maximum lengths as short as just 14 characters in some cases, we implemented the ResourceName function in cloud/azure/deploy/resourcename.go to normalize the names and force them to meet the restrictions.

However, that creates a high likelyhood of name collisions from the resulting normalized, truncated names. Resulting in duplicate resource names and/or duplicate Pulumi resource URNs.

[tjholm]

Since Azure has overly restrictive resource name requirements, such as maximum lengths as short as just 14 characters, we implemented the ResourceName function in cloud/azure/deploy/resourcename.go to normalize the names and force them to meet the restrictions.

However, that creates a high likelyhood of name collisions from the resulting normalized, truncated names. Resulting in duplicate resource names and/or duplicate Pulumi resource URNs.

That's fair enough in this case we should address the URNs and unique azure resource names as separate issues, as changing either of them for a resource is a destructive operation need to ensure we aren't going to clobber resources that contain data.

Truncation of any kind should not be used for URNs

[tjholm]

For migration of resources where we want to change the URN see:
https://www.pulumi.com/docs/iac/concepts/options/aliases/