Skip to content
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

Closed
wants to merge 5 commits into from

Conversation

solsson
Copy link
Contributor

@solsson solsson commented Jul 25, 2017

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.

@solsson solsson added the addon label Jul 25, 2017
@solsson solsson force-pushed the single-node branch 3 times, most recently from 3d40b80 to 66a3ab1 Compare July 27, 2017 03:07
@solsson
Copy link
Contributor Author

solsson commented Jul 28, 2017

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 kubectl apply might re-scale your cluster when you only wanted a pod definition change.

@solsson
Copy link
Contributor Author

solsson commented Nov 26, 2017

Quite interesting: https://kafka.blog/posts/scaling-down-apache-kafka/

@clintfred
Copy link

I'm probably the only slow one, but it took me a minute to realize that the intention was to use the single-node branch to get the "small cluster". @solsson Would you accept a PR to the README to make this clearer? Is the intention to eventually include this as a separate sub-dir in the kafka/ directory?

@solsson
Copy link
Contributor Author

solsson commented Feb 28, 2018

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.

@solsson
Copy link
Contributor Author

solsson commented Mar 26, 2019

#253 will replace this kind of branch and the endless rebase it requires

@solsson solsson closed this Mar 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants