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

Move scylla config creation into the operator #2329

Open
Tracked by #2326
ylebi opened this issue Jan 13, 2025 · 0 comments
Open
Tracked by #2326

Move scylla config creation into the operator #2329

ylebi opened this issue Jan 13, 2025 · 0 comments
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@ylebi
Copy link
Collaborator

ylebi commented Jan 13, 2025

Is this a bug report or feature request?

  • Feature Request

What should the feature do:
Scylla config should be built in the operator, then represented as a CM/Secret and mounted into the container. Same goes for the args. Currently it is build in a sidecar which has several disadvantages:

  • the sidecar has to run exactly the same image as the operator which is impossible to enforce and breaks with rolling tags
  • if any remote call fails it cases a restart
  • we can't trigger rolling restarts on changes
  • wastes live api call, the operator already has caches with data that needs to be substituted
  • is build again for every replica, instead of the operator doing it once
  • if config building fails we end up with 1 replica down, while the operator would find out sooner and would stop before trying the first replica
  • it can't be revisioned
  • needs extra RBAC
  • it doesn't honor the Three laws of controllers (ownerRefs, adoption, release)
  • it needs additional arguments to know e.g. the manager-agent secret location, while the operator already has all of the prerequisites and caches
  • we can't prevent a rollout with invalid config
@ylebi ylebi added kind/feature Categorizes issue or PR as related to a new feature. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. triage/accepted Indicates an issue or PR is ready to be actively worked on. labels Jan 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

No branches or pull requests

2 participants