hashicorp / terraform

Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.
https://www.terraform.io/
Other
42.73k stars 9.55k forks source link

Add a global custom field #19701

Open immae opened 5 years ago

immae commented 5 years ago

Current Terraform Version

Terraform v0.11.10

Use-cases

Adding a custom field that would be ignored in every terraform actions, but that would be exported for instance by terraform state pull.

Attempted Solutions

Could not find any way to do it globally (searched the documentation)

Proposal

The proposal I’m thinking of is the following : There exists great tools such as this one https://github.com/adammck/terraform-inventory but they are limited in the sense that for every new provider, you need to extract and abstract information from the resource, depending on the provider, to make use of them later. It would be great to have a custom field, that would contain a map and that would be accepted in any resource, regardless of the provider, and that would be exported in terraform state pull. This field would have no other use than to let the user have an abstracted and common way to specify values that he wants to aggregate regardless of the underlying provider.

References

immae commented 5 years ago

NB: I can consider developping it, I first want approval of the idea

mildwonkey commented 5 years ago

Hi @immae! This sounds interesting, but I'm having trouble picturing it. Could you share a little more of your use case, and perhaps an example of what this might look like, both in a configuration file and how it would be used? Thanks for opening this request!

immae commented 5 years ago

Hi @mildwonkey, thanks for your interest. My use case is the following: I use Ansible to install my servers, and Terraform to provision the servers. I also use more than one server provider (in my case, AWS, Hetzner and OVH). If I want to dynamically generate the hosts list (which terraform knows of) from Ansible, I can do a terraform state pull, which gives me a json to parse. However, the problem is that this json has no "standard" structure, since each provider has his way to get information. For instance, I can put the server name in "tags" -> "name" in an aws instance, while in an Hetzner one it would be in "name" field directly. Other information may be needed that cannot always be written in the resource (like role = "RabbitMQ", environment = "production", whatever you can think of)

This makes the parsing of the json dependent on the provider, so each new provider will require specific development to be added to my Ansible dynamic hosts list (in fake code, I have a lot of if provider == "hetzner" then name = resource["name"] elsif provider == "aws" then name = resource["tags"]["name"] else ... to generate my list).

The idea would be to have an arbitrary object (say "customTags") in the resources, that would not be used by the provider, and where I could put any information independently of the provider. In my case, I’d put something like customTags = { name = "Foo"; role = "Bar" }, and use it in my Ansible script as resource["customTags"]["name"]. It’s much easier to use the information when it’s standardized that way than to have to know how the provider is implemented to know where to look for the information.

Is it more clear that way?

mildwonkey commented 5 years ago

It is, thank you for the additional information!

duxbuse commented 1 year ago

I would also like this. My use case is I have some IAM resources and I would like to add an approval_url field to all the resources and then create a custom check in tf_sec to ensure its presence. This way I have a mapping for all IAM permissions to an approval document

nocturn9x commented 1 year ago

Literally nothing happens for 4 years

Nice.

crw commented 1 year ago

Reminder to please use the upvote mechanism (click or add the 👍 emoji to the original post) to indicate your support for this issue. Thanks for the feedback!

immae commented 1 year ago

I used to have a development of this feature but since it never evolved from the "I’ll think of it" state from the maintainer I never sent a PR (and now I don’t have access to it anymore)

Note that pulumi does this kind of thing in a much easier way though