-
Notifications
You must be signed in to change notification settings - Fork 40k
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: remove Initializers (still in alpha) from admission control #58428
kubeadm: remove Initializers (still in alpha) from admission control #58428
Conversation
/lgtm |
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
Do we know when Initializers are expected to hit beta @liggitt?
IIRC, this was added to the list long ago, with the argument that the user would still need to enable the API group manually in order for this to be functional. To me it makes sense to require the user to opt in in both places here
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dixudx, liggitt, luxas Associated issue: #629 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
/test all [submit-queue is verifying that this PR is safe to merge] |
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions here. |
Do I now have to maintain a list of admission controllers, or just enabling the API group is still enough? I would recommend having a specific flag for this, a feature gate, I suppose. It sounds like a terrible UX for someone to try a feature that had been blogged about a lot. |
@errordeveloper For kubeadm users, who still want to use When using this alpha These two args can be configured in |
That is what I suspected. I think that we should add a feature gate that enables it in
a easy way, because user shouldn't have to care about what initializers
they need and in what order.
…On Thu, 18 Jan 2018, 8:38 am Di Xu, ***@***.***> wrote:
@errordeveloper <https://github.com/errordeveloper> For kubeadm users,
who still want to use Initializers, they can use apiServerExtraArgs
through kubeadm config file to enable it when booting up the cluster.
When using this alpha Initializers, you still have to add it into
admission controllers list and pass admissionregistration.k8s.io/v1alpha1
to runtime-config as well.
These two args can be configured in apiServerExtraArgs.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#58428 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAPWS9RvTznZAz52_z08NCCtt5cZAh3lks5tLwMFgaJpZM4RiVky>
.
|
Let's start with documenting what's needed, but I'm open to adding a feature gate for Initializers as well if it doesn't hit beta in v1.10 |
Agree. There is work in progress to significantly improve this: #58123 |
What this PR does / why we need it:
Currently
Initializers
is still in alpha version, which should not be enabled by default, until promoted to beta.For kubeadm users, who still want to use
Initializers
, they can useapiServerExtraArgs
through kubeadm config file to enable it when booting up the cluster.Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes kubernetes/kubeadm#629
Special notes for your reviewer:
/assign @luxas
/area kubeadm
/cc @kubernetes/sig-cluster-lifecycle-pr-reviews
/cc @liggitt @jamiehannaford @timothysc
Release note: