Give control over resources names

[sdib]

Consumers of the module may want to control the name of the created resources, for example if they have a naming convention to follow.

[jcorioland]

Hi @sdib - thanks for submitting the issue. This makes a lot of sense. Are you willing to submit a PR for that one?

[sdib]

Hi @jcorioland, yes I think I can propose something.
I'm wondering how this should be implemented :

• optional feature ? for me yes to keep backward compatibility
• 1 new string variable per name pattern or 1 new object variable with as many attributes as names we have or add new attributes to linux / windows configuration existing variables (would break backward compatibility I guess) ?

Any thoughts from your side ?

[jcorioland]

Hi @sdib - I need to think about it, but for sure it must be optional. Can you try to make a design proposal here so we can discuss about how the TF configuration could looks like with this change? Thank you!

[sdib]

Hello @jcorioland, here are 2 proposals :

1 =>

variable "name_patterns" {
  type = object({
    linux_network_profile_pattern     = string
    linux_network_interface_pattern   = string
    linux_ip_configuration_pattern    = string
    linux_container_group_pattern     = string
    linux_agent_pattern               = string
    windows_network_profile_pattern   = string
    windows_network_interface_pattern = string
    windows_ip_configuration_pattern  = string
    windows_container_group_pattern   = string
    windows_agent_pattern             = string
  })

  default = null
}

caveat I see with this one, is that if you want to control only 1 resource name, you need to provide a pattern for each (until terraform 0.15 comes with optional attributes). Maybe we want to wait this optional attributes feature from terraform to be available before implementing this ?

2 =>

variable "linux_network_profile_pattern" {
  type = string
  default = null
}

variable "linux_network_interface_pattern" {
  type = string
  default = null
}

variable "linux_ip_configuration_pattern" {
  type = string
  default = null
}

variable "linux_container_group_pattern" {
  type = string
  default = null
}

variable "linux_agent_pattern" {
  type = string
  default = null
}
variable "windows_network_profile_pattern" {
  type = string
  default = null
}
variable "windows_network_interface_pattern" {
  type = string
  default = null
}
variable "windows_ip_configuration_pattern" {
  type = string
  default = null
}
variable "windows_container_group_pattern" {
  type = string
  default = null
}
variable "windows_agent_pattern" {
  type = string
  default = null
}

this one offers more fine grained control, but a lot of inputs and <linux/windows>_container_group_pattern may be confusing with the <linux/windows>_agents_configuration.agent_name_prefix

[jcorioland]

Hi @sdib, thanks for the two options proposed. I have a preference for the first one also, that is lighter approach as you can define only the properties that are relevant for you on the complex object, if I am not mistaken. This looks good way to proceed to me!

[jcorioland]

Hey @sdib, have you been able to make some progress on this item?

[aafre]

I ran into this issue at my org where we have a naming policy for resources. Is there an ETA for this update?

[jcorioland]

Hi @aafre - unfortunately we have no ETA for this item, sorry.