how to use this module with multiple resources?

[louien]

I started using this module recently, but I am struggling to understand how it handles random instance numbers when dealing with multiple resources of the same type.

I have the following code, and all I want to do is to have 2 resource groups, with a random instance number at the end (as a suffix).

module "websiteNaming" {
source = "Azure/naming/azurerm"
suffix = [ "n", "web", "dev" ]
prefix = [ "xyz" ]
unique-length = 2
unique-include-numbers = true
}

resource "azurerm_resource_group" "xyz_website" {
name = module.websiteNaming.resource_group.name_unique
location = "West US"
}

resource "azurerm_resource_group" "dof_website2" {
name = module.websiteNaming.resource_group.name_unique
location = "West US"
}

but what I end up with, is 2 resource groups with the same name.

resource "azurerm_resource_group" "xyz_website" {
id = "/subscriptions/xxx-xxxx-xxx/resourceGroups/xyz-rg-n-web-dev-xe"
location = "West US"
managed_by = null
name = "xyz-rg-n-web-dev-xe"
}

resource "azurerm_resource_group" "xyz_website2" {
id = "/subscriptions/xxx-xxxx-xxx/resourceGroups/xyz-rg-n-web-dev-xe"
location = "West US"
managed_by = null
name = "xyz-rg-n-web-dev-xe"
}

All I want to have is something like xyz-rg-n-web-dev-87 and xyz-rg-n-web-dev-76 where the instance numbers are randomly generated.
How can I do this with this module? it sounds strange to have a different naming module for each same type resource - what if I wanted to create a 100 web apps with this module, where the names of the web apps are unique (unique instance number)?

Please help me.

thanks.

[spowser]

It can't generate random characters each time you reference the name_unique property as it's not a method. The unique value has been generated once and then assembled with each resource type available in the format Azure expects for that resource. Wrap your resource group in a module with the naming module and then you can call it as many times as you want.

[ryanl-ee]

I have the same issue. I built a helper module around this to provide a set of naming conventions depending on the way the resource is being used. My preferred naming convention is to append a random ID that is specific to each instance of each resource.

This allows for create_before_destroy to work properly in Azure along with other similar workflows. If a specific resource needs to be replaced with a new unique name, the random_string is shared across all resources named with that module call. This is a problem for a couple of reasons:

• This makes it very difficult to in-place rebuild a subset of resource as the random_string resource must be tainted to generate a new result.
• The compromise workaround encourages single-resource modules (the naming module call and the resource itself) to provide a unique suffix, which creates unnecessary overhead and complexity.
• I considered adding a random_string to my helper module that runs for_each based on each resource output from this module, but that would create (at current count) 247 additional resources. Each random_string would also only be specific to a resource type, which doesn't provide any benefit to the workflows described above as that suffix would be identical between multiple instances of the same resource.
• Additionally, for those of us using HCP Terraform or other services, the pricing structure is per resource. Even with the most efficient usage of random_string, that would DOUBLE the number of resources under management. This is cost prohibitive and creates inflated states.
• I considered using Terraform functions or other approaches to accomplish this as they aren't resources, but the options are either:
  • Some variation of a hash or namespace-based UUID, but since these outputs are predictable this has the same limitations resulting in naming collisions with create_before_destroy.
  • Using something like uuid(), which is not a resource and is randomized each time it's called but is not persisted to state so every resource would need an ignore_changes = [ name ] lifecycle.
  • Maybe some kind of terraform_data with triggers and keepers?
  • A really long random_id that's sliced up? This sounds overly complex to properly correlate.
  • ephemeral resources were just GA'd in 1.10.0, but I'm having trouble imagining how to use them in a way that doesn't have the same limitations as other approaches, and this also feels like an abuse of a resource type intended for secrets management.

...you get the point.

The AWS provider gets around this by providing a name_prefix parameter in addition to name, which handles the random suffix for you. I don't think the Azure provider has an equivalent.

I realize this isn't really a problem specific to this module, but if there were a solution, I would love to see it reflected here.

Has anyone thought of something that overcomes this?

[Arnab-Developer]

Similar issue #71