While this is a separate helm feature vs management of the kafka broker, this is coupled to hypertrace/kafka directly.
For example, creating topics is a simple act, but one that could fail based on changes to https://github.com/hypertrace/kafka
Having this separate requires coordinated knowledge of this existing when updating hypertrace/kafka, and that also implies testing this when the former changes. For example, if you don't, the image layers aren't coherent and the operations could also fail without knowing. In other words, they are quite coupled and coupled things deserve to be in the same repo.
On the other hand, this couples changes to the changes in hypertrace/kafka. However, this repo changes infrequently so far. For example, last non-trivial changes were roughly once in 2 weeks. While there could be some tension versioning hypertrace/kafka due to this, the overall coherence and less things to track seems a higher win. Worst case, as separate tag version could be applied to the helm chart this represents.
Meanwhile, if folding in, the org namespace is also more coherent, and the perceived complexity is limited along with the maintenance advantages.
Since there's a historical tendency to use git submodules, I'll mention explicitly the goal is to remove repositories, not add yet another one. In other words, this repo will be removed or archived/attic'd.
Please vote thumbsup if you agree, or no action if you don't care. If you thumbs down, you must be able to express in objective terms what must be surmounted to progress this topic. eg words like "priority" aren't objective.
While this is a separate helm feature vs management of the kafka broker, this is coupled to hypertrace/kafka directly.
For example, creating topics is a simple act, but one that could fail based on changes to https://github.com/hypertrace/kafka
Having this separate requires coordinated knowledge of this existing when updating hypertrace/kafka, and that also implies testing this when the former changes. For example, if you don't, the image layers aren't coherent and the operations could also fail without knowing. In other words, they are quite coupled and coupled things deserve to be in the same repo.
On the other hand, this couples changes to the changes in hypertrace/kafka. However, this repo changes infrequently so far. For example, last non-trivial changes were roughly once in 2 weeks. While there could be some tension versioning hypertrace/kafka due to this, the overall coherence and less things to track seems a higher win. Worst case, as separate tag version could be applied to the helm chart this represents.
Meanwhile, if folding in, the org namespace is also more coherent, and the perceived complexity is limited along with the maintenance advantages.
Since there's a historical tendency to use git submodules, I'll mention explicitly the goal is to remove repositories, not add yet another one. In other words, this repo will be removed or archived/attic'd.
Please vote thumbsup if you agree, or no action if you don't care. If you thumbs down, you must be able to express in objective terms what must be surmounted to progress this topic. eg words like "priority" aren't objective.