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

apiserver: Fail if dry-run query param is specified #63557

Merged
merged 1 commit into from
May 15, 2018

Conversation

apelisse
Copy link
Member

@apelisse apelisse commented May 8, 2018

Adds a dry-run query parameter now that does nothing but reject the request. The sooner we have this check in master, the safer it will be for clients to send dry-run requests that are not going to be applied nonetheless.

Create a new `dryRun` query parameter for mutating endpoints. If the parameter is set, then the query will be rejected, as the feature is not implemented yet. This will allow forward compatibility with future clients; otherwise, future clients talking with older apiservers might end up modifying a resource even if they include the `dryRun` query parameter.

@k8s-ci-robot k8s-ci-robot added size/S Denotes a PR that changes 10-29 lines, ignoring generated files. do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels May 8, 2018
@@ -318,3 +319,7 @@ func parseTimeout(str string) time.Duration {
}
return 30 * time.Second
}

func isDryRun(url *url.URL) bool {
return len(url.Query()["dry-run"]) != 0
Copy link
Member

Choose a reason for hiding this comment

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

The thing to debate is if this is the way we want to represent dry run. I'd open an issue & send an email to the api machinery list, since this is a bit late in the cycle. It's a very simple change so there shouldn't be a problem but let's be noisy about it.

Copy link
Member

Choose a reason for hiding this comment

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

It's probably OK for this sort of PR (maybe @deads2k won't think so), but you should be aware that this skips all of our ordinary URL parsing code.

Copy link
Contributor

Choose a reason for hiding this comment

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

It's probably OK for this sort of PR (maybe @deads2k won't think so), but you should be aware that this skips all of our ordinary URL parsing code.

I do think it's an example of the feature branch allowing flexibility we wouldn't allow into master. I think that flexibility is very useful when working something like this, but it does undermine the idea that the feature branch is as rigorous as master.

On a related note. If dry-run works well in this branch and the semantics are well described, it seems like a good target to bring into master separately.

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 targeting master :)

The goal is to get dry run as a concept established as early as possible so that it can be relied on to fail safe, since the consequences of submitting a dry run request the server doesn’t know is a dry run is really bad.

Copy link
Member

Choose a reason for hiding this comment

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

Before the parameter is actually used for anything other than a top-level short-circuiting fail like this, I’d expect the create/update/patch handlers to be updated to use the *Options approach and decode parameters just like the other handlers.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, this change is for master and wouldn't make sense for the feature branch.

I agree w/ @liggitt that it needs to go through the right stack before we do anything productive with it. I think this is fine as an easy & safe way to reserve it, though.

Copy link
Member

Choose a reason for hiding this comment

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

looking at all the other *Options structs, we'd add this as dryRun, not dry-run

@apelisse
Copy link
Member Author

apelisse commented May 9, 2018

/retest

@lavalamp
Copy link
Member

lavalamp commented May 9, 2018

David & I talked earlier-- this is good to go if you can just add a test ;)

@k8s-ci-robot k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels May 9, 2018
@apelisse
Copy link
Member Author

apelisse commented May 9, 2018

Added tests, PTAL

}
}

func TestDryRunPatch(t *testing.T) {
Copy link
Member

Choose a reason for hiding this comment

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

also test update?

Copy link
Member Author

Choose a reason for hiding this comment

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

not sure how I missed it :-) Thanks

@apelisse
Copy link
Member Author

I've added the missing test, and s/dry-run/dryRun.

}
}

func TestDryRunDelete(t *testing.T) {
Copy link
Member

@liggitt liggitt May 10, 2018

Choose a reason for hiding this comment

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

deletecollection as well? (with test)

@liggitt
Copy link
Member

liggitt commented May 10, 2018

this covers subresources with standard rest crud handlers. what do we plan to do with subresources that implement "connect" (things like pods/exec, pods/attach, */proxy, pods/portforward, etc)?

@lavalamp
Copy link
Member

lavalamp commented May 10, 2018 via email

@liggitt
Copy link
Member

liggitt commented May 10, 2018

I think those should always reject dryRun requests--there's no way to pass along the dryRun invariant.

wouldn't you expect them to exercise admission/validation the same way a normal request would, and stop short of execution? especially for exec/attach, I could see that being really handy.

@lavalamp
Copy link
Member

lavalamp commented May 10, 2018 via email

@apelisse apelisse force-pushed the dry-run-path branch 2 times, most recently from d52d7b5 to 143a068 Compare May 11, 2018 23:04
@apelisse
Copy link
Member Author

I've had to change more test code than I wish I had to, but I think this is correct.

return nil, nil
}

// TestUnimplementedRESTStorage ensures that if a rest.Storage does not implement a given
Copy link
Member Author

Choose a reason for hiding this comment

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

I should update that comment...

@@ -318,3 +319,7 @@ func parseTimeout(str string) time.Duration {
}
return 30 * time.Second
}

Copy link
Member

Choose a reason for hiding this comment

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

It might be a good idea to add a TODO here explaining that this will be moved to our versioned structs like other parameters before being implemented for real.

@lavalamp
Copy link
Member

Thanks for putting the test like we discussed IRL :)

I have one suggestion but I think it's optional.

I think, given where you put the check, it's not possible to screw it up by doing start-up plumbing wrong, so there's no need to do an integration check.

I'm not sure how to make this work for aggregated apiservers--we can't force people to upgrade. I will discuss in the issue.

/lgtm
/approve

@k8s-ci-robot k8s-ci-robot added lgtm "Looks good to me", indicates that a PR is ready to be merged. approved Indicates a PR has been approved by an approver from all required OWNERS files. labels May 14, 2018
@apelisse
Copy link
Member Author

/retest

@apelisse
Copy link
Member Author

/release-note-none

@k8s-ci-robot k8s-ci-robot added release-note-none Denotes a PR that doesn't merit a release note. and removed do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. labels May 14, 2018
@lavalamp
Copy link
Member

lavalamp commented May 14, 2018 via email

@liggitt
Copy link
Member

liggitt commented May 14, 2018

Yeah, definitely needs a release note

@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. and removed release-note-none Denotes a PR that doesn't merit a release note. labels May 14, 2018
@apelisse
Copy link
Member Author

Tentatively added a release note.

@lavalamp
Copy link
Member

Edited the release note a bit :)

/lgtm

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: apelisse, lavalamp

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-github-robot
Copy link

Automatic merge from submit-queue (batch tested with PRs 63603, 63557, 62015). If you want to cherry-pick this change to another branch, please follow the instructions here.

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. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants