Skip to content

Make sure that we have reasonable defaults #335

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

Closed
ChunyiLyu opened this issue Sep 14, 2020 · 3 comments
Closed

Make sure that we have reasonable defaults #335

ChunyiLyu opened this issue Sep 14, 2020 · 3 comments
Assignees
Milestone

Comments

@ChunyiLyu
Copy link
Contributor

ChunyiLyu commented Sep 14, 2020

Context
As part of the upgrade and GA effort, it will be good if we can make sure that the operator is using setting defaults when deploy rabbitmq. We should check defaults that the operator is setting for:

  1. statefulSet deployment
  2. rabbitmq.conf
  3. any other defaults that impact the behavior of rabbitmq or how it is deployed.

This is to make sure that 1. the operator is using reasonable defaults; 2. we minimize the chance that we need to change the default behavior in the future.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

@ChunyiLyu ChunyiLyu added this to the GA milestone Oct 20, 2020
@mkuratczyk mkuratczyk self-assigned this Oct 22, 2020
@mkuratczyk
Copy link
Collaborator

mkuratczyk commented Oct 27, 2020

Things to discuss:

  1. Do we want to use conf.d format for the settings we generate?

  2. At some point we added these settings:

cluster_formation.node_cleanup.interval         = 30
cluster_formation.node_cleanup.only_log_warning = true

Is it the right thing to do?

  1. startupProbe is still being discussed Pod stuck in Terminating state #409

  2. Is it really necessary to set terminationGracePeriodSeconds to such a high value?

  3. Should we rename persistence given multiple volumes could be used?

  4. No command set in the StatefulSet. Do we want to keep it like that?

  5. Rename cluster-links to erlang in the headless service

@mkuratczyk
Copy link
Collaborator

We document the default configuration in https://www.rabbitmq.com/kubernetes/operator/using-operator.html#additional-config. We need to update it once we are done with default configuration changes.

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

No branches or pull requests

3 participants