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

Validation Webhook: Auto-Accept Status Updates #7010

Merged
merged 14 commits into from
Aug 23, 2022

Conversation

sam-heilbron
Copy link
Contributor

@sam-heilbron sam-heilbron commented Aug 23, 2022

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:

  • I included a concise, user-facing changelog (for details, see https://github.com/solo-io/go-utils/tree/master/changelogutils) which references the issue that is resolved.
  • If I updated APIs (our protos) or helm values, I ran make -B install-go-tools generated-code to ensure there will be no code diff
  • I followed guidelines laid out in the Gloo Edge contribution guide
  • I opened a draft PR or added the work in progress label if my PR is not ready for review
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • I have added tests that prove my fix is effective or that my feature works

@github-actions github-actions bot added the keep pr updated signals bulldozer to keep pr up to date with base branch label Aug 23, 2022
@sam-heilbron sam-heilbron marked this pull request as ready for review August 23, 2022 12:03
@solo-changelog-bot
Copy link

Issues linked to changelog:
#6990

return false, &multierror.Error{Errors: []error{WrappedUnmarshalErr(err)}}
}

specsAreEqual := reflect.DeepEqual(newResource.Spec, oldResource.Spec)
Copy link
Member

Choose a reason for hiding this comment

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

proto.Equal?

Copy link
Member

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.?

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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

@github-actions
Copy link

github-actions bot commented Aug 23, 2022

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 🌎


specsAreEqual := reflect.DeepEqual(newResource, oldResource)
if specsAreEqual {
logger.Debugf("Skipping validatation. Reason: status only update")
Copy link
Contributor

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")
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
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
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Comment on lines 562 to 570
// 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)}}
}
Copy link
Contributor

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

Copy link
Contributor

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

Copy link
Contributor

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)

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 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.

Copy link
Contributor

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

Copy link
Contributor Author

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!

@sam-heilbron
Copy link
Contributor Author

Copy link
Member

@EItanya EItanya left a 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!

@jenshu
Copy link
Contributor

jenshu commented Aug 23, 2022

LGTM as well

nfuden
nfuden previously approved these changes Aug 23, 2022
@soloio-bulldozer soloio-bulldozer bot merged commit 7fff0fc into master Aug 23, 2022
@soloio-bulldozer soloio-bulldozer bot deleted the vwh/accept-status-updates branch August 23, 2022 19:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
keep pr updated signals bulldozer to keep pr up to date with base branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants