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

⚠ Add AdmissionReviewVersions support for webhook #474

Merged

Conversation

jiachengxu
Copy link
Contributor

This PR is a follow-up of #469
This PR adds support to config AdmissionReviewVersions for webhook, and this is required for generating v1 webhook.
Instead of defaulting it for the user, now if it is not specified, we return an error, so this is a breaking change.

@k8s-ci-robot k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Aug 21, 2020
@k8s-ci-robot k8s-ci-robot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label Aug 21, 2020
@jiachengxu
Copy link
Contributor Author

/cc @vincepri @alvaroaleman @estroz

Copy link
Member

@vincepri vincepri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/approve

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jiachengxu, vincepri

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 21, 2020
SideEffects: c.sideEffects(),
// TODO(jiachengxu): AdmissionReviewVersions becomes required in admissionregistration/v1, here we default it
// to `v1` and `v1beta1`, and we should support to config the `AdmissionReviewVersions` as a marker.
AdmissionReviewVersions: []string{defaultWebhookVersion, "v1beta1"},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if this might be nice to keep this as a default for v1, and have AdmissionReviewVersions: []string{"v1beta1"} as the default for v1beta1 or not default them (even though it is probably good practice to do so).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For v1beta1, I think we don't need to default it since it will be defaulted by kube-apiserver to []string{"v1beta1"} if it is not specified: https://github.com/kubernetes/api/blob/master/admissionregistration/v1beta1/types.go#L318-L320

For v1, I am not sure if we should default it. I would slightly prefer to ask the user to set AdmissionReviewVersions because it is required in v1, and don't really want to hide this to the user, defaulting it without notifying may cause some unknown issues in their environments/projects. WDYT?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the flip side, breaking marker format for users using defaults isn’t great, although this is a requirement for v1 and they can pretty easily keep using v1beta1 if they choose. Is there a policy on breaking marker format @DirectXMan12 @vincepri?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is definitely a breaking change as you outlined, if we're supporting both we should have defaults only when necessary. When using v1, we should make sure there is some sort of validation to not break users

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we’re defaulting only when necessary then we probably shouldn’t here, since these need to be set for v1 but controller-gen can’t know which admission review versions the webhook server is using.

@estroz
Copy link
Contributor

estroz commented Aug 24, 2020

/lgtm

Unhold when ready to merge @jiachengxu

/hold

@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Aug 24, 2020
@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 24, 2020
@jiachengxu
Copy link
Contributor Author

/unhold

@k8s-ci-robot k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Aug 25, 2020
@k8s-ci-robot k8s-ci-robot merged commit 9a9db70 into kubernetes-sigs:master Aug 25, 2020
@mythi
Copy link
Contributor

mythi commented Sep 4, 2020

Any plans to add this is to a release? AFAICS, 0.4.0 is not compatible with controller-runtime releases which uses v1beta1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants