Add ability to Amend Module Resource Attributes

[Stretch96]

Terraform Version

Terraform v1.7.3

Use Cases

Hello 👋

I have had a thought about the state of Terarform 'modules', and the difficulty of relying on 3rd party modules and not having the ability to quickly fix or amend a resource that has been created within a module (If the module becomes unmaintained)

Other coding frameworks have appeared to slightly solve this issue by having 'plugins', 'packages', 'add-ons' etc able to have parts of their functionality re-written.

eg. a WordPress's function in a plugin can be simply overwritten by redefining it ...

If I create a public Terraform module, for a 'secure' AWS RDS instance, but accidentally make a mistake ...

# main.tf
resource "aws_db_instance" "secure_ish" {
  [...]
  publicly_accessible = true
  [..]
}

The user will use it like this:

module "a_secure_rds" {
  source = "./securish-db-instance"
}

The users of this module then either have to wait for me to fix it, or the user will create a fork, and maintain the fork ...

Attempted Solutions

N/A

Proposal

My proposal is, to add an optional resource_attribute_amendments block to the module block

Allow resource attributes within modules to be added/deleted/updated

Possibly a resource_attribute_amendments block could be specified to amend resource attributes within a module.

eg.

module "a_secure_rds" {
  source = "./securish-db-instance"

  resource_attribute_amendments = {
    aws_db_instance.secure_ish.publicly_accessible = false,
  }
}

References

N/A

[apparentlymart]

Thanks for this feature request, @Stretch96!

This is an interesting idea, but also something that doesn't really have any precedent in Terraform today. We would typically expect that, as you said, someone would report a bug with you as the module author and then you would publish a fixed module, or if you don't want to do that then they would fork the module and maintain their own version.

We do need to be particularly careful with anything that explicitly pierces the abstraction offered by the module. In the example you shared, for instance, this would mean that if you wanted to rename aws_db_instance.secure_ish, or move it into a module, or otherwise refactor it later then you might be blocked from doing so because a caller is depending on your implementation details. We must be cautious about anything which grows the scope of what is covered by "backward compatibility" for a module author, because otherwise we risk making it essentially impossible to change a shared module at all after it's been initially written, if everything about how you implemented the module is subject to patching and overriding by callers.

[rohit-gohri]

What do you think about the approach patch-package or yarn patch takes for the JS/NPM ecosystem? i.e. rather than trying to provide support for modifying modules via syntax it can be done via a post-init step where a git patch is applied on the downloaded modules.

And by taking git patch approach, this would also make it easy to test PRs for modules or even encourage users to submit fixes via PRs since they would already have a git patch ready.

[rohit-gohri]

Built a small proof of concept cli to test out the idea - https://github.com/rohit-gohri/tf-patch