Allow providers to create meta arguments for resources

[jason-johnson]

Terraform Version

newest

Use Cases

As a user of terraform, I want to apply a naming convention to all my resources.
As a user of terraform, I want to apply a naming convention to things which are not resources but still need unique names.

Attempted Solutions

I am the author of the namep terraform provider. In my experience creating terraform configurations for companies, there is always a naming convention in place. Trying to apply this to every resource name individually obviously is not suitable. My first attempt was using a terraform module but this has a lot of limitations as well.

So in the end I created a terraform provider, called namep which allowes users to specify a convention for their names and then use data resources from the provider to compute these names based on those conventions. I download known azure resources from a project which has them, along with various meta information about the resources to determine what is allowed in the name.

The reason namep only uses data resources is because these are available at plan time. Azure names are basically the identity for the resource so them not being known at plan time means using namep would cause resources to get recreated a lot. Using data resources solves this issue. Another nice property is that namep can detect problems with the name (e.g. too long, invalid characters, etc.) at plan time instead of at apply time.

The issue I have are:

• using a data resource doesn't feel very clean. In fact I'd say it's a hack but it was the best way I found to make this work
• for part of the naming computation to work, I need to know what kind of resource the name is being used in. Right now clients are forced to specify the type where the name will be used and this is prone to errors since there is nothing that will detect it if the wrong type is used.

Proposal

If my namep provider had the ability to create a meta argument or a function or something, this could be put directly in the resource to determine the computed name. What ever the mechanism was, it would be important that it would be able to determine the type of the resource it was used with. There can't be a reference from the type to some namep entity because that would make a circular relationship.

Some proposed syntax might be something like:

resource "azurerum_resource_group" "main" {
  namep_field = name            # this will compute the name for an azurerm_resource_group and fill in the "name" field with the result
}

resource "some_other_resource" "example" {
  name = "some_resource"
  namep_custom_field = api_name
}

It might even be interesting to only allow the meta arguments to apply to certain resources.

References

No response

[jason-johnson]

Alternatively the provider could add a function (as #27696) or builtin variable, something like:

resource "azurerum_resource_group" "main" {
  name = namep_gen_name()
}

or

resource "azurerum_resource_group" "main" {
  name = $namep_gen_name
}

so long as the provider would be able to determine the type of the resource using the function or variable.

[jbardin]

Hi @jason-johnson,

I would be a very large change to design a method for a provider to alter the schema from another provider, but would Provider Defined Functions suit your needs?

[jbardin]

Oh, I see you linked to a related issue in your follow up. Yes, provider functions are part of the upcoming v1.8 release: https://github.com/hashicorp/terraform/blob/v1.8.0-beta1/CHANGELOG.md

[jason-johnson]

Hi @jbardin, this looks very interesting. Critical for this to work would be that the function can figure out what resource is calling it. Either pick it up from the context or if there is some way for the resource to pass itself to the function. Without that, it is still an improvement but will continue to have the vulnerability that the user can simply pass the wrong data type in causing the wrong name to be produced.

[jbardin]

Yes, right now the user would always need to specify the type name in some way, because the type name is only part of the containing resource. This could be a function argument, or specialized functions per known type.

There is no precedent in the language to include any configuration context in any RPC calls, so including the name of the top-level block in the function call may require some large architectural changes to Terraform, and research into the possible impact of the proposed changes. Given the work we've done to keep the configuration context and provider protocol independent, this would not be a change I would expect to see move forward without extensive design work.

[jason-johnson]

Ok, thanks for the info @jbardin. Upon reflection, this is already a radical quality of life improvement for my provider.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.