Azure / Azure/Azure-Landing-Zones
Allow specifying a naming convention (pattern) instead of customizing each individual resource's name
- Dominant language
- PowerShell
- Stars
- 96
- Forks
- 70
- Avg merge
- 3d 1h
- Merged PRs (30d)
- 7
Description
### Is there an existing issue for this?
- [x] I have searched the existing issues
### Infrastructure as Code Type? (Required)
both
### Starter Module? (Required)
not relevant
### Use Case (Required)
Customers might have a preferred naming convention pattern that is not exactly like the CAF pattern. In that case, customizing individual resource names is the current solution, but it's tedious to remember to name every single RG and resource separately.
### Proposed Solution (Required)
A better approach would be to take a single parameter that is a string containing placeholders for the different segments of a resource name. Then at runtime, the TF or Bicep would perform string replacement of the placeholders with actual values.
Customers should not be required to provide a placeholder for every possible segment.
An example naming convention pattern could look like this: `{rtype}-{workloadName}-{env}-{loc}-{seq}`. (This would match the CAF suggestion and could be the default value of the parameter.) Customers could choose to re-arrange the segments however they like and add fixed values to it (like an org abbreviation) like this: `MS-{workloadName}-{env}-{rtype}-{loc}-{seq}`
Something along the lines of what's illustrated here in Bicep (though it's not complete, it doesn't account for all possible resource types): https://github.com/SvenAelterman/BicepTemplate/blob/main/common-modules/createValidAzResourceName.bicep
### Important Factoids (Optional)
A re-usable valid resource name generation module would add standalone value too and could be leveraged by the ALZ modules.
See https://github.com/Azure/Azure-Verified-Modules/issues/1156
### References (Optional)
_No response_
Contributor guide
Research direction
Start by reviewing the proposed Bicep example and Azure Verified Modules issue #1156, then trace how naming is currently handled in the Terraform and Bicep ALZ modules. Done should mean a reusable naming-pattern parameter supports reordered and omitted segments, fixed text, and consistent resource-name generation in both implementations.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, terraform
- Domain
- cloud, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100