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

Support automatic and graceful config changes #182

Open
benbromhead opened this issue May 31, 2019 · 2 comments
Open

Support automatic and graceful config changes #182

benbromhead opened this issue May 31, 2019 · 2 comments
Labels
enhancement New feature or request

Comments

@benbromhead
Copy link
Collaborator

Upon a user modifying a configmap, we need to detect this change and gracefully propagate it throughout the cluster that references that configmap.

@benbromhead benbromhead added the enhancement New feature or request label May 31, 2019
@benbromhead benbromhead added this to To do in Go Porting Project via automation May 31, 2019
@alourie alourie removed this from To do in Go Porting Project Sep 18, 2019
@smiklosovic
Copy link
Collaborator

smiklosovic commented Feb 7, 2020

Depends whether the changes to be propagated require the restart of a node or not.

If they do and we need to restart a cluster in a rolling fashion, the rolling restart would have to be coordinated from the operator itself. We might be receptive on the changes of ConfigMap in operator and if a change is detected (another problem how to know something has actually changed), we would restart in rolling fashion. There is already restart operation in place and we just need to code a logic in operator for that.

If it is enough to change yaml's and this would be propagated internaly by Cassandra itself (is that ever the case?) I am not sure how to tackle this one because we have ConcatenatedYaml resolver and we are not actually having any cassandra.yaml file as such ...

@smiklosovic
Copy link
Collaborator

relates to #107 , e.g. for image changes, we just update and delete so it is restarted with new one.

On the other hand, these changes are done on statefulset itself, we are not patching our CRDs. If patching should be possible on our CRDs, we would have to detect this change on reconciliation and change / patch underlying statefulset accordingly.

I would focus only on use cases where changes to raw statefulset will not change what we want, e.g. Cassandra configuration itself. Whatever is achievable by Kubernetes itself should be delegated to it or at most we should write some layer on top of that so operator orchestrates it nicely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants