-
Notifications
You must be signed in to change notification settings - Fork 38.8k
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
kubeadm: Control plane config moved to substructs #70371
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks @rosti
1b0c1ad
to
dfa69f6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rosti thanks for this PR!
I have no strong opinion on the usage of a shared struct vs dedicated struct.
Everything else seems ok
Only one question. The Change about HostPathMount.Writable to ReadOnly is going to be addressed in another PR?
dfa69f6
to
b0bdb41
Compare
/test pull-kubernetes-e2e-gce-100-performance |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/approve
LGTM but will defer to @fabriziopandini for final call
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: rosti, timothysc The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This appears to be blocking a number of your other PRs. |
@rosti please rebase and then ping me for lgtm |
In v1alpha3's, control plane component config options were nested directly into the ClusterConfiguration structure. This is cluttering the config structure and makes it hard to maintain. Therefore the control plane config options must be separated into different substructures in order to graduate the format to beta. This change does the following: - Introduces a new structure called ControlPlaneComponent, that contains fields common to all control plane component types. These are currently extra args and extra volumes. - Introduce a new structure called APIServer that contains ControlPlaneComponent and APIServerCertSANs field (from ClusterConfiguration) - Replace all API Server, Scheduler and Controller Manager options in ClusterConfiguration with APIServer, ControllerManager and Scheduler fields of APIServer and ControlPlaneComponent types. Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
b0bdb41
to
d14c27a
Compare
/lgtm |
/test pull-kubernetes-e2e-kops-aws |
/test pull-kubernetes-integration |
What type of PR is this?
/kind api-change
What this PR does / why we need it:
In v1alpha3's, control plane component config options were nested directly into the ClusterConfiguration structure. This is cluttering the config structure and makes it hard to maintain. Therefore the control plane config options must be separated into different substructures in order to graduate the format to beta.
This change does the following:
Introduces a new structure called ControlPlaneComponent, that contains fields common to all control plane component types. These are currently extra args and extra volumes.
Introduce a new structure called APIServer that contains ControlPlaneComponent and APIServerCertSANs field (from ClusterConfiguration)
Replace all API Server, Scheduler and Controller Manager options in ClusterConfiguration with APIServer, ControllerManager and Scheduler fields of APIServer and ControlPlaneComponent types.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Refs kubernetes/kubeadm#911
Special notes for your reviewer:
/cc @kubernetes/sig-cluster-lifecycle-pr-reviews
/area kubeadm
/assign @luxas
/assign @timothysc
/assign @fabriziopandini
This will be followed by a PR that introduces an API server timeout option (as discussed at office hours on Oct 24th.
Does this PR introduce a user-facing change?: