search

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.97k stars 9.57k forks source link

Expose config rewriting hook to providers #24688

Open paddycarver opened 4 years ago

paddycarver commented 4 years ago

Current Terraform Version

v0.12.24

Use-cases

When I upgrade a Terraform provider with terraform init -upgrade, I would like the provider to automatically rewrite my configs to be valid with the new version of the provider, removing any fields that are no longer supported, and otherwise massaging my config into the shape the provider thinks it should be in.

Attempted Solutions

N/A

Proposal

Right now Terraform's RPC protocol has an RPC for UpgradeResourceState; this allows the provider to receive a copy of the current state, and set the state it believes should exist, which lets providers massage state into the correct format automatically for users.

I'm proposing that we expose similar functionality, but for config files. This could be done by adding an UpgradeResourceConfig RPC call, or adding config information to the UpgradeResourceState request and response types.

The SDK could be expanded to field these requests and offer a customizable function that exposed either the raw HCL or an abstraction on top of it for providers to examine and potentially rewrite in response to this call, to update it to use the recommended fields and settings for the current version of the provider. For example, fields that have been removed could be deleted from the config automatically, fields that are deprecated in favor of other fields could be removed with the new fields replacing them automatically, potentially. Things that used to be ints or booleans could become strings or even objects or blocks automatically.

We could expose this in a few ways; it could run automatically, as state upgrades do now. But that could cause problems in automation, if a config is upgraded and not exposed back to the user, it won't be persisted, which isn't ideal. It could happen when terraform init -upgrade is run, when the provider is upgraded. Or it could happen in a separate terraform upgrade or terraform migrate command that users could run after upgrading, to rewrite their configs.

By happening as the result of a user command, the user could have a chance to inspect the config before it is applied, and commit the changes back to source control.

This could mitigate and reduce the cost of breaking changes in providers, which, while avoided, are an unavoidable reality providers have to deal with. Currently, the only avenue for handling breaking changes is enumerating them in the changelog and writing an upgrade guide, which users need to read through, manually check against their configs, and then manually apply changes to. While that may always be necessary, a lot of this work is automatable, and exposing this interface to providers allows them the option to provide a better upgrade experience for their users.

References

N/A

paultyng commented 4 years ago

If there is an abstraction for config generation, it could potentially be reused in import code, especially when modeling dependency.