-
Notifications
You must be signed in to change notification settings - Fork 446
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
Validation Webhook: Auto-Accept Status Updates #7010
Conversation
…gloo into vwh/accept-status-updates
Issues linked to changelog: |
return false, &multierror.Error{Errors: []error{WrappedUnmarshalErr(err)}} | ||
} | ||
|
||
specsAreEqual := reflect.DeepEqual(newResource.Spec, oldResource.Spec) |
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.
proto.Equal
?
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.
Also, what about metadata, do we not care about label changes, etc.?
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.
Yeah I was thinking about this and erred on the side of "if it's not a spec change, allow it". One example of a problematic change is:
You could change the label of a VirtualService, which is selected by a Gateway, and that would mean that the Gateway no longer selects any VS's and should reject the change.
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.
You could change the label of a VirtualService, which is selected by a Gateway, and that would mean that the Gateway no longer selects any VS's and should reject the change.
wouldn't this be a reason for not skipping validation when there's a metadata-only change?
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.
Yup! Just pushing up an update
projects/gateway/pkg/services/k8sadmission/validating_admission_webhook.go
Show resolved
Hide resolved
Visit the preview URL for this PR (updated for commit 40fe50c): https://gloo-edge--pr7010-vwh-accept-status-up-44jybh9x.web.app (expires Tue, 30 Aug 2022 18:52:06 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 |
projects/gateway/pkg/services/k8sadmission/validating_admission_webhook.go
Outdated
Show resolved
Hide resolved
projects/gateway/pkg/services/k8sadmission/validating_admission_webhook.go
Show resolved
Hide resolved
|
||
specsAreEqual := reflect.DeepEqual(newResource, oldResource) | ||
if specsAreEqual { | ||
logger.Debugf("Skipping validatation. Reason: status only update") |
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.
add resource name/namespace/kind here too?
|
||
specsAreEqual := reflect.DeepEqual(newResource, oldResource) | ||
if specsAreEqual { | ||
logger.Debugf("Skipping validatation. Reason: status only update") |
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.
logger.Debugf("Skipping validatation. Reason: status only update") | |
logger.Debugf("Skipping validation. Reason: status only update") |
return false, &multierror.Error{Errors: []error{WrappedUnmarshalErr(err)}} | ||
} | ||
|
||
// A status-only update will only differ by status and generation, so we nil both fields before comparing |
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.
does resourceVersion not change on status updates?
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.
Yeah good call. I tried adding a kube2e test, but it's tricky to test, given that we still update generation and other metadata fields, so its hard to identify if the auto-accept of status does anything. Ill keep working on one siince I think it will be necessary to prove out/ensure we don't have a regression.
// For update requests, we check to see if this is a status update | ||
// If it is, we do not need to validate the resource | ||
var newResource, oldResource crdv1.Resource | ||
if err := json.Unmarshal(admissionRequest.Object.Raw, &newResource); err != nil { | ||
return false, &multierror.Error{Errors: []error{WrappedUnmarshalErr(err)}} | ||
} | ||
if err := json.Unmarshal(admissionRequest.OldObject.Raw, &oldResource); err != nil { | ||
return false, &multierror.Error{Errors: []error{WrappedUnmarshalErr(err)}} | ||
} |
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.
rather than do it this way... should we hash it instead and compare hashes? that is what hashing was intended for
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 see we hash the spec, but i mean hash the whole resource with our generated hash functions.. just like our emitters
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.
this should ignore the status but also ignore any fields on the spec we want opted out here as well (which could cause similar issues)
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.
If we do that and there are new fields on the CRD that our current version of gloo doesnt care about then it will still generate validations.
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.
but hashing is faster agreed
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.
Yeah I think that's cleaner. I think I'll need to pass in the typed resource into the function for the 'oldResource'. I'll update!
/kick https://storage.googleapis.com/solo-public-build-logs/logs.html?buildid=f78e19e9-dcd9-4065-9a5b-d14f4bff3bf2 consul works as expected |
projects/gateway/pkg/services/k8sadmission/validating_admission_webhook.go
Show resolved
Hide resolved
projects/gateway/pkg/services/k8sadmission/validating_admission_webhook.go
Show resolved
Hide resolved
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.
These changes make sense to me!
LGTM as well |
Description
Auto-accept status updates, instead of requiring a full translation run
Context
The validation webhook executes a full translation run to determine whether a proposed change is valid. Status only changes will not affect the validity of the proposed change, and therefore it is both unnecessary and expensive to run translation for status only changes.
Checklist:
make -B install-go-tools generated-code
to ensure there will be no code diff