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

Validate _examples block and warn the user if they changed it seemingly by accident. #8123

Merged
merged 1 commit into from
Jun 3, 2020

Conversation

markusthoemmes
Copy link
Contributor

Proposed Changes

As briefly discussed in Slack, this is a proof-of-concept that validates the _examples block against a computed hash of the block. This allows us to warn users if they are changing the _examples block (and thus likely doing the wrong thing for their config) while still allowing us to update the defaults in a release.

Release Note

NONE

@knative-prow-robot knative-prow-robot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label May 28, 2020
@googlebot googlebot added the cla: yes Indicates the PR's author has signed the CLA. label May 28, 2020
@knative-prow-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: markusthoemmes

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

@knative-prow-robot knative-prow-robot added approved Indicates a PR has been approved by an approver from all required OWNERS files. area/test-and-release It flags unit/e2e/conformance/perf test issues for product features labels May 28, 2020
Copy link
Contributor

@vagababov vagababov left a comment

Choose a reason for hiding this comment

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

Can we verify that the hash changed in the CM UTs?
Should be cheap?

if oldHash, ok := newObj.Labels["knative.dev/exampleHash"]; ok {
newHash := fmt.Sprintf("%x", sha256.Sum256([]byte(newObj.Data["_example"])))[:9]
if oldHash != newHash {
return errors.New("_examples block edited, you likely wanted to create an unindentet configuration")
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
return errors.New("_examples block edited, you likely wanted to create an unindentet configuration")
return errors.New("_examples block edited, you likely wanted to create an unindented configuration")

@markusthoemmes
Copy link
Contributor Author

@vagababov I think with this mechanism the verify codegen thingy would catch it too but sure, we can have a look at that too.

@vagababov
Copy link
Contributor

UTs are faster and people usually run them. I never run verify codegen :)

@markusthoemmes
Copy link
Contributor Author

But CI does! 😂 Will add those once this is deemed useful generally.

@vagababov
Copy link
Contributor

Yeah, it's like an hour later :)

@knative-prow-robot knative-prow-robot added size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels May 29, 2020
@knative-test-reporter-robot

The following jobs failed:

Test name Triggers Retries
pull-knative-serving-unit-tests 0/3

Failed non-flaky tests preventing automatic retry of pull-knative-serving-unit-tests:

pkg/reconciler/route.TestUpdateDomainConfigMap
pkg/reconciler/route.TestUpdateDomainConfigMap/newdefault.net


apiVersion: caching.internal.knative.dev/v1alpha1
kind: Image
metadata:
Copy link
Member

Choose a reason for hiding this comment

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

Did you mean to drop this? 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nah, I just did because it annoyed me on reapply locally 😂. Will be taken out once I have a final PR for this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Was pushed by accident.

@markusthoemmes markusthoemmes changed the title [POC] Validate _examples block and warn the user if they changed it seemingly by accident. Validate _examples block and warn the user if they changed it seemingly by accident. Jun 3, 2020
@markusthoemmes
Copy link
Contributor Author

@mattmoor @vagababov @julz This one is ready for another look! pkg changes have landed.

// Check that the hashed exampleBody matches the assigned label, if present.
gotChecksum, hasExampleChecksumLabel := orig.Labels[configmap.ExampleChecksumLabel]
if hasExampleBody && hasExampleChecksumLabel {
wantChecksum := fmt.Sprint(configmap.Checksum(exampleBody))
Copy link
Member

Choose a reason for hiding this comment

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

don't think it really matters, but this is probably our last chance to change it so I'll just mention out loud so we can be completely sure we want it this way: this is formatting the checksum as a uint rather than in hex, which would be (slightly) more concise and a bit (I think) more usual for a checksum. i.e. I think I'd've expected this to be fmt.Sprintf("%08x", configmap.Checksum(exampleData)) (and that's what the example_test of the crc32 package does).

The difference is between e.g. 3000002650 and b2d0685a for the first config-map in the diff.

@julz
Copy link
Member

julz commented Jun 3, 2020

Love it, only minor hesitation is (since this is our last chance!) we should be completely sure we're ok that the checksums are formatted as ints rather than hex, not that it's the end of the world either way just slightly unusual, I think. Other than that lgtm.

@markusthoemmes
Copy link
Contributor Author

/hold

I want to implement @julz suggestion.

@knative-prow-robot knative-prow-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jun 3, 2020
@markusthoemmes markusthoemmes force-pushed the webhook-test branch 2 times, most recently from fc08079 to 24eb98b Compare June 3, 2020 15:48
@markusthoemmes
Copy link
Contributor Author

/unhold

My work here should be done!

@knative-prow-robot knative-prow-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jun 3, 2020
Copy link
Contributor

@vagababov vagababov left a comment

Choose a reason for hiding this comment

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

/lgtm

@knative-prow-robot knative-prow-robot added the lgtm Indicates that a PR is ready to be merged. label Jun 3, 2020
Copy link
Member

@julz julz left a comment

Choose a reason for hiding this comment

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

/lgtm

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. area/test-and-release It flags unit/e2e/conformance/perf test issues for product features cla: yes Indicates the PR's author has signed the CLA. lgtm Indicates that a PR is ready to be merged. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants