Feature Request - user specified naming convention

[roblongdon-contino]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

I would like more freedom around the naming convention in use. The code relies on the rootid var to provide the basis of resource naming. Ideally I would like to prefix and suffix all elements and even choose a different constant per resource type than rootid.

For example, to be able to meet the following naming convention of : mg-<company code>-<type> the code would require a means to prefix the provided management group. E.g. ${prefix}-${root_id}-platform

Resources (non MGs) have a prefix and suffix option but these still include the rootid. Perhaps in this case a user specified var could be used. E.g. ${prefix}-${altroot_id}-resourcex-${suffix}

I have tried to change the locals being used and also looked at overrides but the locals are deeply embedded and in most cases locals containing other locals. I find it hard to customise and not break something else. My skills in Terraform are not advanced so perhaps I'm missing something, any guidance would be appreciated.

Thanks in advance.

[janegilring]

+1

I am also involved in a scenario where we would like to be able to choose a different constant per resource type than root_id. Also, resource groups is desired to have a specific prefix (rg-).

[krowlandson]

Thank you for logging this request @roblongdon-contino and awaiting our response.

This is actually a hot topic currently and we are discussing this in the background already but are yet to decide the best approach. We avoided allowing too much (easy) flexibility around resource naming due to the need to follow patterns to allow scaling out to multiple instances programmatically.

All resources can already be given custom names but this is undocumented and done through the advanced object within each of the respective configuration inputs.

For simpler scenarios like replacing the root_id prefix mentioned by @janegilring, we do support specifying a custom prefix and/or suffix for resources within each scope (management/connectivity) using the following:

  configure_connectivity_resources = {
    # <attributes removed>
    advanced = {
      resource_prefix = "my-prefix"
      resource_suffix = "my-suffix"
    }
  }

  configure_management_resources = {
    # <attributes removed>
    advanced = {
      resource_prefix = "my-prefix"
      resource_suffix = "my-suffix"
    }
  }

This is quite a simple modification though and will not cover the resource type specific prefixes.

To do that, you would need to reverse engineer the path which sets the name via the advanced.custom_settings_by_resource_type input within these same inputs.

You can start tracking this back from the following code which shows an example of how the logic is implemented to determine resource names in the module: https://github.com/Azure/terraform-azurerm-caf-enterprise-scale/blob/1288f401ad8cf85b3e527729a4dddded58aef2ef/modules/management/locals.tf#L78-L82

Please note that these are still experimental features which is why they are not documented, so please use with caution!

[MarcelHeek]

What I would like it to be able to incorporate the Azure Cloud Adoption Framework - Terraform provider logic to generate the resource names for e.g. the management capability. We use this naming provider in the context of the caf-terraform-landingzones module to generate names in accordance with naming conventions and MS recommendations.

https://github.com/aztfmod/terraform-provider-azurecaf

[Eslam10]

I did it as below, not for the prefix/suffix but the full name,

  configure_connectivity_resources = {
    advanced = {
      custom_settings_by_resource_type = {
        azurerm_resource_group = {
          dns = {
            (var.connectivity_settings.location) = {
              name = "NAME"
            }
          }
        }
      }
    }
}
  configure_management_resources = {
    advanced = {
      custom_settings_by_resource_type = {
        azurerm_resource_group = {
          management = {
            name = "NAME"
          }
        },
        azurerm_log_analytics_workspace = {
          management = {
            name = "NAME"
          }
        },
        azurerm_automation_account = {
          management = {
            name = "NAME"
          }
        }
      }
    }
}

[manfred0191]

I would also really appreciate if the model at least would give the opportunity to use the naming convention that MSFT calls "best practise"

https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-naming

[matt-FFFFFF]

Hi @manfred0191

We are considering a CAF naming standard option for the next major version.

We feel that the intention should be to adopt the CAF standards but need to make existing deployments aware of the potential for resource recreation.

It is likely that we will include an optional flag to adopt the pre v.next standards.

Would this work for you?

[manfred0191]

Yep, that sounds great.

[LaurentLesle]

Suggest you wait for version 2 of the provider that will provide a data source to generate a name for a resource type - https://github.com/aztfmod/terraform-provider-azurecaf/issues/159

@[Nepomuceno]

[jtracey93]

Tagging @danycontre for awareness as discussed yesterday about naming across ALZ (all implementations) and AVD accelerator

[jtracey93]

Trigger ADO Sync

[krowlandson]

Pinning this issue for better visibility as this is a common ask.

[krowlandson]

ACTION: Include documentation on how to change resource names in update

[krowlandson]

Trigger ADO Sync

[KrishIntMSFT]

How about Archive Period, where we could define as input along with retention period.

[krowlandson]

How about Archive Period, where we could define as input along with retention period.

@KrishIntMSFT, unfortunately the archive period can only be set at the table level, not at the workspace level. This is documented in MS Docs: How retention and archiving work

As such, this is not something we would be able to consider within the ALZ module due to the infinite options needed to cover differing customer requirements for this capability.

[dani3lheidemann]

Hi @Eslam10, thanks for your example! Helped a lot. However, I'm not able to configure a custom name for a virtual wan resource -.- may you have a working example? Thanks a lot!

[matt-FFFFFF]

Locking this issue to be used as a referece.

[matt-FFFFFF]

We will make naming a 1st party feature of a future major release but the advanced block is the way to achieve this for now