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

This comment has been minimized.

@lavalamp

lavalamp May 8, 2018

Member

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.

This comment has been minimized.

@lavalamp

lavalamp May 8, 2018

Member

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.

This comment has been minimized.

@deads2k

deads2k May 9, 2018

Contributor

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.

This comment has been minimized.

@liggitt

liggitt May 9, 2018

Member

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.

This comment has been minimized.

@liggitt

liggitt May 9, 2018

Member

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.

This comment has been minimized.

@lavalamp

lavalamp May 9, 2018

Member

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.

This comment has been minimized.

@liggitt

liggitt May 10, 2018

Member

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

@apelisse

This comment has been minimized.

Copy link
Member Author

apelisse commented May 9, 2018

/retest

@lavalamp

This comment has been minimized.

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 and removed size/S labels May 9, 2018

@apelisse

This comment has been minimized.

Copy link
Member Author

apelisse commented May 9, 2018

Added tests, PTAL

}
}

func TestDryRunPatch(t *testing.T) {

This comment has been minimized.

@lavalamp

lavalamp May 9, 2018

Member

also test update?

This comment has been minimized.

@apelisse

apelisse May 10, 2018

Author Member

not sure how I missed it :-) Thanks

@apelisse apelisse force-pushed the apelisse:dry-run-path branch from 3314338 to 4a5f43c May 10, 2018

@apelisse

This comment has been minimized.

Copy link
Member Author

apelisse commented May 10, 2018

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

}
}

func TestDryRunDelete(t *testing.T) {

This comment has been minimized.

@liggitt

liggitt May 10, 2018

Member

deletecollection as well? (with test)

@liggitt

This comment has been minimized.

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

This comment has been minimized.

Copy link
Member

lavalamp commented May 10, 2018

@liggitt

This comment has been minimized.

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

This comment has been minimized.

Copy link
Member

lavalamp commented May 10, 2018

@apelisse apelisse force-pushed the apelisse:dry-run-path branch 2 times, most recently from d52d7b5 to 143a068 May 11, 2018

@apelisse

This comment has been minimized.

Copy link
Member Author

apelisse commented May 11, 2018

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

This comment has been minimized.

@apelisse

apelisse May 12, 2018

Author Member

I should update that comment...

@apelisse apelisse force-pushed the apelisse:dry-run-path branch from 143a068 to 2d980fa May 14, 2018

@apelisse apelisse force-pushed the apelisse:dry-run-path branch from 2d980fa to 9861392 May 14, 2018

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

This comment has been minimized.

@lavalamp

lavalamp May 14, 2018

Member

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

This comment has been minimized.

Copy link
Member

lavalamp commented May 14, 2018

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

@apelisse

This comment has been minimized.

Copy link
Member Author

apelisse commented May 14, 2018

/retest

@apelisse

This comment has been minimized.

Copy link
Member Author

apelisse commented May 14, 2018

/release-note-none

@lavalamp

This comment has been minimized.

Copy link
Member

lavalamp commented May 14, 2018

@liggitt

This comment has been minimized.

Copy link
Member

liggitt commented May 14, 2018

Yeah, definitely needs a release note

@apelisse

This comment has been minimized.

Copy link
Member Author

apelisse commented May 14, 2018

Tentatively added a release note.

@lavalamp

This comment has been minimized.

Copy link
Member

lavalamp commented May 14, 2018

Edited the release note a bit :)

/lgtm

@k8s-ci-robot

This comment has been minimized.

Copy link
Contributor

k8s-ci-robot commented May 14, 2018

[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

This comment has been minimized.

Copy link
Contributor

k8s-github-robot commented May 15, 2018

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.

@k8s-github-robot k8s-github-robot merged commit 6aa6051 into kubernetes:master May 15, 2018

16 checks passed

Submit Queue Queued to run github e2e tests a second time.
Details
cla/linuxfoundation apelisse authorized
Details
pull-kubernetes-bazel-build Job succeeded.
Details
pull-kubernetes-bazel-test Job succeeded.
Details
pull-kubernetes-cross Skipped
pull-kubernetes-e2e-gce Job succeeded.
Details
pull-kubernetes-e2e-gce-device-plugin-gpu Job succeeded.
Details
pull-kubernetes-e2e-gke Skipped
pull-kubernetes-e2e-kops-aws Job succeeded.
Details
pull-kubernetes-integration Job succeeded.
Details
pull-kubernetes-kubemark-e2e-gce Job succeeded.
Details
pull-kubernetes-local-e2e Skipped
pull-kubernetes-local-e2e-containerized Skipped
pull-kubernetes-node-e2e Job succeeded.
Details
pull-kubernetes-typecheck Job succeeded.
Details
pull-kubernetes-verify Job succeeded.
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.