-
Hi! We have some microservices which implements a template to create a KafkaTopic. When we uninstall these charts, the kafkatopic managed by the chart first gets deleted but at the time of the next reconciliation it gets recreated by the topicoperator. Our kafka configuration is as follows: (using strimzi 0.30.0) apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
name: ...
spec:
kafka:
replicas: {{.Values.kafka.replicas }}
listeners:
...............................................
authorization:
type: simple
storage:
...............................................
config:
auto.create.topics.enable: false
delete.topic.enable: false
offsets.topic.replication.factor: 1
transaction.state.log.replication.factor: 1
transaction.state.log.min.isr: 1
default.replication.factor: 1
min.insync.replicas: 1
metricsConfig:
type: jmxPrometheusExporter
valueFrom:
configMapKeyRef:
name: kafka-metrics
key: kafka-metrics-config.yml
zookeeper:
replicas: 1 #(live: 3)
storage:
type: persistent-claim
class: managed-premium
size: 10Gi
deleteClaim: false
entityOperator:
topicOperator: {}
userOperator: {} I have found several (mostly closed) issues regarding this 'behaviour', but non of them discussed the fact that how the I have a feeling that once the Is it intended to work this way with the above configuration? Do you experience the same? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
When you set So overall, if you have |
Beta Was this translation helpful? Give feedback.
When you set
delete.topic.enable
tofalse
, a topic that already exists cannot be deleted regardless of yourauto.create.topics.enable
setting.auto.create.topics.enable
control only how it is auto-created if it does not exist. But when you disable deletion, it will already exist so it will not matter.So overall, if you have
delete.topic.enable: false
, then yes, if you delete the KafkaTopic resource, it will be just recreated by the operator as it will still exist in Kafka. This is expected behavior.