-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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 defaulting and validation infrastructure for DomainMappings #9886
Add defaulting and validation infrastructure for DomainMappings #9886
Conversation
This commit adds the infrastructure for defaulting and validation and a minimal amount of defaulting/validation.
Codecov Report
@@ Coverage Diff @@
## master #9886 +/- ##
==========================================
+ Coverage 87.78% 87.83% +0.04%
==========================================
Files 181 183 +2
Lines 8591 8607 +16
==========================================
+ Hits 7542 7560 +18
+ Misses 800 799 -1
+ Partials 249 248 -1
Continue to review full report at Codecov.
|
@@ -0,0 +1,86 @@ | |||
package main |
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.
I wonder if we can fold controller's and webhooks into one pod with the leader-election work being done 🤔. It'd conflate scaling of one with the other, but maybe that's fine for extensions like this?
cc @mattmoor
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.
is there a big advantage to doing that vs. keeping them separate? As you say it seems a shame to lose the ability to scale them independently (ideally the webhook doesn't need to have a cache of every ingress in the system for example, and the failure cases -> probes/PDBs are pretty different), plus when this lands they'll be separate anyway so seems easier to keep them that way and avoid future problems.
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.
The short answer is yes, and it's how I've run mink ~forever for reasons we don't need to dive into here.
The longer answer is that I see this as a downstream distribution problem and I'd like to enable either or, and my bias is generally towards the most flexible (unopinionated) upstream option.
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.
Totally see the point in mink fwiw where the goal is to have one simple thing to deploy, for this it seems a little more flexible to have them separate, especially since that's how this will eventually land anyway when we lose the alpha flag.
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.
Ack, didn't want to block anything.
/lgtm I'd be happy to have the other meta conversation separately, but I don't think we should block this on it. In particular, I wonder about it in the context of things like |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: julz, mattmoor 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 |
@@ -48,6 +48,10 @@ type DomainMapping struct { | |||
|
|||
// Verify that DomainMapping adheres to the appropriate interfaces. | |||
var ( | |||
// Check that Route may be validated and defaulted. |
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.
Possibly a copy and paste error?
// Check that Route may be validated and defaulted. | |
// Check that DomainMapping may be validated and defaulted. |
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.
hah, yeah, think so :) Will fix in next PR tomorrow since Im touching this anyway - thanks!
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.
I guess no Conversion webhook?
I have a few readability style nits, but I'll just send a pr with those, since I got late to the party :)
labels: | ||
serving.knative.dev/release: devel | ||
webhooks: | ||
- admissionReviewVersions: ["v1", "v1beta1"] |
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.
Wasn't your API Alpha? :)
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.
iiuc these are the versions of the AdmissionReview object we accept, not the version of the validated object we accept, see https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#request
errs = errs.Also(apis.ErrMissingField("name")) | ||
} | ||
|
||
if ref.Namespace != "" && ref.Namespace != md.Namespace { |
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.
Can ref.Namespace
be empty? Given you default it?
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.
mmmm dont know, maybe not :) tbh I just wanted to put some validation here to test stuff out, will swap this out for https://github.com/knative/pkg/blob/master/apis/duck/v1/knative_reference.go#L84 in next PR anyway when I fill in all the actual validation/defaulting :).
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.
no Conversion webhook because v1alpha1 is the only supported version, so I think it doesn't make sense yet to allow any other version?
Part I-lost-count of #9713.
This commit adds the basic infrastructure for defaulting and validation and a minimal amount of defaulting/validation to make sure it all works. More validation/defaulting to follow in next PR.
/assign @mattmoor @vagababov