We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
I'll just copy&paste our chat with @sircthulhu
kvaps: I've got an idea, what if we move all four of these flags into a configMap included with envFrom?
envFrom
--initial-advertise-peer-urls
--initial-cluster
--initial-cluster-state
--initial-cluster-token
It seems they are only relevant during initialization and might change over the lifetime of the cluster itself.
Kir: We can remove them after the cluster is created :)
Except for the state.
state
kvaps: Hold on, but what about adding new replicas and re-bootstrapping the old ones? How else will they know where to join?
With this approach, they will always have up-to-date information at startup.
Kir: Overall, you're right :)
kvaps: From the operator's side, we would only need to implement the deletion of old replicas.
Scaling up should handle itself.
The text was updated successfully, but these errors were encountered:
Move initial config to ConfigMap from sts cli flags (#56)
b72c708
This is important when scaling cluster up for this operation to be zero down time fixes #25
Successfully merging a pull request may close this issue.
I'll just copy&paste our chat with @sircthulhu
kvaps:
I've got an idea, what if we move all four of these flags into a configMap included with
envFrom
?--initial-advertise-peer-urls
--initial-cluster
--initial-cluster-state
--initial-cluster-token
It seems they are only relevant during initialization and might change over the lifetime of the cluster itself.
Kir:
We can remove them after the cluster is created :)
Except for the
state
.kvaps:
Hold on, but what about adding new replicas and re-bootstrapping the old ones? How else will they know where to join?
With this approach, they will always have up-to-date information at startup.
Kir:
Overall, you're right :)
kvaps:
From the operator's side, we would only need to implement the deletion of old replicas.
Scaling up should handle itself.
The text was updated successfully, but these errors were encountered: