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
If I remove a topic setting from my config, while the setting is still on the broker, topicctl would not delete it and leave it as it is
Found 1 key(s) set in cluster but missing from config:
-------------------------+----------------
KEY | CLUSTER VALUE
-------------------------+----------------
message.timestamp.type | LogAppendTime
-------------------------+----------------
These will be left as-is."
Is there any reason to specifically avoid deleting topic settings when there is a mismatch between config and broker? I think that would make topic settings management actually declarative.
I can see the potential for damages (provide an empty config by mistake) when allowing this, though updates go through user confirmation and there could be a flag to enable the destructive behavior.
If there is any interest in having this feature I would try to build it.
The text was updated successfully, but these errors were encountered:
fpacifici
changed the title
Support for deleting settings present on the broker but not in config (with flag to enable)
Support for topic settings deletion if they are present on the broker but not in config (with flag to enable)
Jun 4, 2024
Hi,
I really like the tool. thanks.
If I remove a topic setting from my config, while the setting is still on the broker, topicctl would not delete it and leave it as it is
Topicctl though supports deletion of a setting by setting it to empty string.
https://github.com/segmentio/topicctl/blob/master/pkg/admin/brokerclient.go#L770-L774
Is there any reason to specifically avoid deleting topic settings when there is a mismatch between config and broker? I think that would make topic settings management actually declarative.
I can see the potential for damages (provide an empty config by mistake) when allowing this, though updates go through user confirmation and there could be a flag to enable the destructive behavior.
If there is any interest in having this feature I would try to build it.
The text was updated successfully, but these errors were encountered: