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

Rely on a configMap for operator-level settings #3401

Closed
sebgl opened this issue Jul 7, 2020 · 1 comment · Fixed by #3570
Closed

Rely on a configMap for operator-level settings #3401

sebgl opened this issue Jul 7, 2020 · 1 comment · Fixed by #3570
Assignees
Labels
>enhancement Enhancement of existing functionality

Comments

@sebgl
Copy link
Contributor

sebgl commented Jul 7, 2020

Forked from #2791.

The number of flags that can be passed to the operator binary is becoming quite large. It may feel more natural for users to tweak them through a configMap rather than modifying the operator StatefulSet spec. Providing a default config with comments explaining each setting would also make the possible options easier to understand.

Should we setup a mechanism to auto-reload the config, or auto-kill/restart the operator when the configuration changes, or should we let users deal with it?

@sebgl sebgl added the >enhancement Enhancement of existing functionality label Jul 7, 2020
@pebrc
Copy link
Collaborator

pebrc commented Jul 9, 2020

Another aspect here is that when ECK is installed via Operator Lifecycle Manager users typically do not have the ability to tweak startup flags but a auto-reloaded configuration file would be a way to work around that restriction.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>enhancement Enhancement of existing functionality
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants