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
Who is this for and what problem do they have today?
We use multiple topics for long-term storage of mission-critical events. Accidental deletion or deletion due to an error of these topics would result in productive downtime and require time to restore the data from backups.
What are the success criteria?
There is a delete_topic_enable cluster-level property, which can be set to false to disable deletion of topics. If set to true topics should be deletable. Default should be true
Why is solving this problem impactful?
Again, no accidental deletions of topics (with mission-critical data) and therefore no consequential downtime.
There is a kafka_nodelete_topics cluster property. However, this one requires manually adding all (relevant) topics and a user may accidentally overwrite delete protection for internal topics.
If this is implemented, there should be a follow-up for the operator. If the property is set to false and a Topic defined by a CRD is removed, the operator should log/output a warning.
This risk is significantly amplified in GitOps environments using the Redpanda operator/CRDs and tools like Flux, where accidental removals or the cascading deletion of parent Kustomizations can trigger the immediate, automated destruction of topics without manual oversight.
The Terraform provider has a allow_deletion property, but this one seems to protect only at the Terraform level itself.
Who is this for and what problem do they have today?
We use multiple topics for long-term storage of mission-critical events. Accidental deletion or deletion due to an error of these topics would result in productive downtime and require time to restore the data from backups.
What are the success criteria?
There is a
delete_topic_enablecluster-level property, which can be set tofalseto disable deletion of topics. If set totruetopics should be deletable. Default should betrueWhy is solving this problem impactful?
Again, no accidental deletions of topics (with mission-critical data) and therefore no consequential downtime.
Additional notes
delete.topic.enableproperty, see Apache Kafka documentation.delete.topic.enablesimilar to Kafka #1929, which has been closed because it was stale.falseand a Topic defined by a CRD is removed, the operator should log/output a warning.