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

RFE: change cluster config as day 2 operation #1581

Closed
DanyC97 opened this issue May 30, 2019 · 7 comments
Closed

RFE: change cluster config as day 2 operation #1581

DanyC97 opened this issue May 30, 2019 · 7 comments
Assignees
Labels
area/UX 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.
Milestone

Comments

@DanyC97
Copy link

DanyC97 commented May 30, 2019

MOVED

"change the cluster" is now tracked in:

#970

Is this a BUG REPORT or FEATURE REQUEST?

Choose one: FEATURE REQUEST

Feature description

Following a deployment a K8s cluster using kubeadm on a cloud and/or on-prem environement, i'd like to be able to change the default values for K8s core components (scheduler, api, kube-prox, controller, kubelet) as well as addons like coreDNS without having to scale up/ add a new control plane node.

On slack we had a very useful conversation and with help from @fabriziopandini we found out that there is already a discussion going on - see here.

While i understand that maybe day 2 operation might be covered by cluster-api i think we should definitely have the option on kubeadm (as standalone) just because a lot of folks already started using kubeadm while cluster-api is not ready for consumption and missing this feature does cause a bad experience for operators

@neolit123
Copy link
Member

possible overlap with:
#1379

@neolit123 neolit123 added area/UX kind/feature Categorizes issue or PR as related to a new feature. labels May 30, 2019
@DanyC97
Copy link
Author

DanyC97 commented Jun 3, 2019

so here are some use cases i do see

@anguslees maybe you want to chime in and add your thoughts / use cases ?

  • User wants to modify K8s core components flags and perform a "reload" w/o having to "replace" (scale up) the control plane node
  • User wants to modify the cluster addon installed by kubeadm and perform a "reload"

@neolit123 i've deliberately avoided providing specific flags as is very hard to know what folks wants to change in a prod env. As such my view is that all flags should be allowed to be changed.

@neolit123
Copy link
Member

@fabriziopandini
this issue can be reused for the 1.16 "change the cluster" / reconf ideas.

@neolit123 neolit123 added the priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. label Jul 12, 2019
@neolit123 neolit123 changed the title RFE: change cluster config as day 2 operation Tracking issue for changing the cluster (reconf) Aug 3, 2019
@neolit123
Copy link
Member

@fabriziopandini i've changed the title and we can use this ticket as the tracking issue for "change the cluster". we can update the OP with user stories, pending PRs and KEP links.

in terms of KEPs the deadline passed, so this would need an exception (deadline for exceptions is the 19th of Aug).

please move the milestone to 1.17 if see fit.

@fabriziopandini
Copy link
Member

@neolit123
IMO there are several tickets tracking slightly different variations of the same topic, which is changing the configuration of a running cluster. My proposal is to close this and conflate everything under #1698

@neolit123
Copy link
Member

@fabriziopandini
i think before we do that the operator idea needs a quick discussion in terms of it's architecture.
with the original "change the cluster" we planned calling kubeadm commands on each node which is safe, while the operator is something that will be topology aware and have super powers.

@neolit123 neolit123 changed the title Tracking issue for changing the cluster (reconf) RFE: change cluster config as day 2 operation Aug 5, 2019
@neolit123
Copy link
Member

closing in favor of:
#970

(it links to this issue for example user story)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/UX 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.
Projects
None yet
Development

No branches or pull requests

3 participants