[Feature Request]: Name changes require clean/migration/revert to old name for Template Spec/Bicep Reg/Artifact publishing

[ahmadabdalla]

Describe the bug

Recent change to our naming standards for publishing and modules duplicates on the publishing mechanism for Bicep registry, template spec and artifacts.

We need to perform some clean ups on the CARML CI and possibly provide guidance for customers who will migrate to the latest version of CARML.

As per the comment from @eriqua :

"Thanks @krbar for the heads up. Nothing prevents us from cleaning up, since we're not leveraging them for any solution. However, that may not be the case for customers adopting the CI environment. Changing the publishing naming convention is a bigger breaking change than it is the module folder renaming. It must be advertised properly once the release will be out. I'm even wondering if we shouldn't keep the old publishing naming instead to avoid this side effect. In the end this is not something needed for the BPR alignment."

To reproduce

Publishing

Code snippet

No response

Relevant log output

No response

[AlexanderSehr]

I'd advotate against keeping the original name as it may lead to unexpected outcomes (even though it's painful).

On the one hand, if I have a module such as recovery-services/vaults/backup-storage-config, I'd expect a module with that name and not Microsoft.RecoveryServices/vaults/backupStorageConfig.

And on the other hand, if we'd try to automate this, I strongly supect customers that have created custom modules / constructs (that work well in the CI environment) would then also be involuntarily impacted.

[eriqua]

Just throwing alternatives to discuss: a setting switch allowing either the resourceType naming or the resourcePath naming. It should be an easy implementation. The second could better fit users adopting the CI environment for custom modules and constructs, since it would have a 1:1 mapping with the module path name. The first would anyway be the easiest to avoid breaking changes for solution references and the 800 templatespecs per rg limit.

[eriqua]

Before the renaming:
moduleFolderPath = resourceType

Example: Microsoft.RecoveryServices/vaults/backupStorageConfig

Published modules (TemplateSpecs/PrivateBicepRegistry/ADOUniversalPackages) following moduleFolderPath/resourceType naming

After the renaming:
moduleFolderPath != resourceType

Example:
moduleFolderPath = Microsoft.RecoveryServices/vaults/backupStorageConfig
resourceType = Microsoft.RecoveryServices/vaults/backupStorageConfig

Need to decide published modules (TemplateSpecs/PrivateBicepRegistry/ADOUniversalPackages) naming

• Option1: use resourceType (old naming)
  Pros: same as old naming. No breaking change for users adopting CI environment
  Cons: no mapping between local moduleFolderPath and published module naming

• Option2: use moduleFolderPath
  Pros: mapping between local moduleFolderPath and published module naming
  Cons:

  • breaking change for users adopting CI environment
  • issue with template specs limitation, max 800 resources of the same type in the same RG

• Option 3: allow option to choose if adopting resourceType or moduleFolderPath naming for published modules through input variable in https://github.com/Azure/ResourceModules/blob/main/settings.yml.

[ahmadabdalla]

I would vote for option 3. Helps with backwards compatibility and gives users the options. Maybe we should default it the original version (option 1) we had before?

[eriqua]

Team decides to go with option 3: allow option to choose if adopting resourceType or moduleFolderPath naming for published modules through input variable in https://github.com/Azure/ResourceModules/blob/main/settings.yml.

The default option should be the new naming. Clear comments explaining the intention of the new setting must be added both in code and in the wiki