[feature] Support ignoring api_version for updates

[stevehipwell]

When updating resources it can be useful to update a resource with a new API version, in fact this is a fundamental part of Kubernetes. The current behaviour tries to destroy and re-create a resource when this happens which is bad from a Terraform aspect with cyclic dependencies and bad from a Kubernetes aspect where something is being removed when it could just be updated (made even worse if this happens to be a CRD).

It would be really useful to add an argument to kubectl_manifest that would allow the upgrade to ignore API versions. The logic for this could be internal (e.g. upgrade_apis = true would support going from networking.k8s.io/v1beta1 -> networking.k8s.io/v1) or customizable (e.g. upgrade_apis = ["networking.k8s.io/v1beta1"] would allow the new API version to replace the old API version if it was networking.k8s.io/v1beta1) or a full override (e.g. upgrade_apis = true skipping the API version check).

Thanks for this provider, it's great.

[chreichert]

Are there any plans to implement this? It is currently preventing us from upgrading Strimzi Kafka operator to higher versions, as the upgrade forces us to upgrade the API version on deployed resources, that are deployed using the kubectl provider.

[chreichert]

@gavinbunney : Sorry for asking again. This feature would be very important for us. Reason is, that when you are forced to update the API version on an already deployed resource (e.g. kafkas.strimzi.io), this is currently not possible. The provider would destroy and recreate the resource, which is nothing you would want, when your active running Kafka cluster in production will be destroyed.