You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello,
we are using terraform to deploy a kafka cluster handled by strimzi operator (this request can be useful for many other cases) through a Custom Resource Definition handled by the operator itself.
The problem is that, modifying a simple config on the crd through kubernetes_manifest module, destroys completely (causing service to be down) and then recreate the kafka object, while if applying the same yaml with kubectl, the strimzi operator will do a blue/green deployment of the new configuration.
Saying it differently: we need a way to only update some terraform resources, so that an operator handles itself if it should be destroyed/recreated/updated_only...
Description
Hello,
we are using terraform to deploy a kafka cluster handled by strimzi operator (this request can be useful for many other cases) through a Custom Resource Definition handled by the operator itself.
The problem is that, modifying a simple config on the crd through kubernetes_manifest module, destroys completely (causing service to be down) and then recreate the kafka object, while if applying the same yaml with kubectl, the strimzi operator will do a blue/green deployment of the new configuration.
Saying it differently: we need a way to only update some terraform resources, so that an operator handles itself if it should be destroyed/recreated/updated_only...
Potential Terraform Configuration
with:
kube_manifests/kafka/strimzi-kafka-cluster2.yaml =>
if i change "default.replication.factor" using kubernetes_manifest:
Actual behavior
and then the whole kafka cluster is destroyed an the recreated:
What we want
so that the strimzi operator (like any other operator), handles it (like it does if we update its definition through kubectl):
Proposal
adding a parameter like: force_update_only at resource level in kubernetes_manifest
References
Community Note
The text was updated successfully, but these errors were encountered: