Segment employee here. Our Kafka runbook looks 100X cleaner after this tool was rolled out by Ben and folks. One of my favorite parts is how it makes dangerous things harder :)
> Replica placement strategy<p>This is huge, currently you have to manually specify placement for all replicas when you increase the replication factor for a topic. Do this for many topics and it quickly becomes very tedious and error-prone. Thanks for this, I'm very excited to try it out!
"""Many of these were shaped by our experiences making AWS changes with Terraform and Kubernetes changes with kubectl. We wanted an equivalent to these for Kafka!"""<p>so use this topicctl for advanced topic changes.... and the more primitive kafkactl[1] for basic stuff?<p>What about the 10 or so other GUI managers like this one?
<a href="https://github.com/cloudhut/kowl" rel="nofollow">https://github.com/cloudhut/kowl</a> [2]<p>[1]<a href="https://github.com/deviceinsight/kafkactl" rel="nofollow">https://github.com/deviceinsight/kafkactl</a><p>[2] <a href="https://news.ycombinator.com/item?id=24099037" rel="nofollow">https://news.ycombinator.com/item?id=24099037</a>
kafka-gitops [1] is another declarative topic/acl management tool that enables a planfile/apply strategy.<p>[1]: <a href="https://github.com/devshawn/kafka-gitops" rel="nofollow">https://github.com/devshawn/kafka-gitops</a>
That looks very interesting! About managing YAMLs like we'd do with kubectl as explained in the article, how does topicctl differ both in concept and operation from Strimzi's Kafka Operator for Kubernetes? I know, they are a different company etc but that Kafka operator is gitops-friendly and everything so I'm honestly trying to compare them as managing Kafka is a REALLY HARD problem, so kudos for trying to make it easier!