Migrating a kubernetes_manifest from one apiVersion to another without deleting and recreating

[jcmcken]

Description

When you have a kubernetes_manifest at one version (say v1beta1) and you want to migrate it to a different version (v1), currently, this provider forces a complete replacement of that resource within the Kubernetes cluster (i.e. delete the resource and then create a new one).

But this is a dangerous workflow and differs compared to the Kubernetes data model. Deleting a resource can lead to deletion of real, stateful data.

So typically, we rely on Kubernetes' ability to represent one object in multiple different API versions at the same time. For example, you may create an object with API version v1beta1, but Kubernetes can represent that resource in API version v1. Then it's up to the API controller to decide how to interpret the object. In this way an API controller can provide a seamless transition between one API version and another.

The only solution at this time is to forcibly delete kubernetes_manifest objects from your TF state, and then re-import using the new API version. But this is cumbersome and prone to user error.

Potential Terraform Configuration

Same as existing method for changing the API version, except instead of deleting and recreating the resource, import the new API version and just change the data shape stored in the state.

Perhaps this could also be an option (disabled by default) to preserve compatibility with existing behavior. E.g. an option called upgrade_api_version (boolean) that, if true, changes the behavior from a forced replacement to what I described above.

References

• https://github.com/hashicorp/terraform-provider-kubernetes/pull/1593

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment