-
Notifications
You must be signed in to change notification settings - Fork 735
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
addon: Initially scaled to minimize resource use #44
Conversation
3d40b80
to
66a3ab1
Compare
If we begin to depend on preparation scripts like c481cba we might want to use the small scale as default, and increment the numbers in such scripts. It's a gotcha anyway that a |
a3ea952
to
3ce7ddd
Compare
Quite interesting: https://kafka.blog/posts/scaling-down-apache-kafka/ |
I'm probably the only slow one, but it took me a minute to realize that the intention was to use the |
So far we've avoided templating and manifest duplication. Branches and forks is probably the only way to keep avoiding both of them. I have a similar challenge currently in #155 (comment). Maybe "official forks" would be the most practical approach to offering different kinds of initial setup for different use cases? The reason being that we recommend everyone to fork anyway. The readme would contain a link and a one liner per official fork. We actually had that in https://github.com/Yolean/kubernetes-kafka/tree/v3.0.0#kafka-on-kubernetes but I'm very short on time to maintain even the main line, so I removed those due to lack of attention. I'd be glad to see maintainers for such official forks. The single node experiment could definitely need more work, such as tuning for lower memory use. Or are there advantages with permanently open PRs, for example wrt how github issues works? We could have a one liner per PR. |
reverting #140 to avoid "does not meet the required replication factor '3' for the offsets topic"
#253 will replace this kind of branch and the endless rebase it requires |
Good for Minikube and other experimental setups.
Should be compatible with
bootstrap.servers
containing the regular 3 kafka nodes, because the first one exists.Note that to scale up after create, the zookeeper config must be restored. It hard codes the list of instances.