[kubernetes/kubernetes] Create dry-run query parameter on CREATE/UPDATE/PATCH/DELETE handlers (#63559)
Antoine Pelisse
Discussed this morning as part of the wg-apply with @liggitt @lavalamp @seans3
Since we're planning on adding a dry-run mechanism to apply, we would like to have that mechanism in place as early as possible, so that future clients don't get their dry-run requests accepted and performed while running against older servers.
I'm suggesting that we add a "dry-run" query parameter whose content wouldn't matter on each modifying end-points (create, update, patch, delete).
Like the following end/points?dry-run. The value of dry-run will be ignored, so dry-run=false would still apply the dry-run (I think it's safer to consider requests as dry-run proactively).
I've started a pull-request to implement this behavior (#63557)
@kubernetes/sig-api-machinery-api-reviews
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
Daniel Smith
It's a little weird that dry-run=false would trigger dry-run behavior.
Jordan Liggitt
It's a little weird that dry-run=false would trigger dry-run behavior.
Agree. I'd expect behavior consistent with other booleans like the watch param
Antoine Pelisse
Agree. I'd expect behavior consistent with other booleans like the watch param
That's a great point, I'll look at this pattern.
Daniel Smith
I'm not sure how to make this work for aggregated apiservers. We could make the aggregator do this check, but then we'd need to provide (in the future) some way for the aggregator to understand whether the downstream apiservers support it. Also, this would be the first such thing checked by the aggregator, which is a little odd. This is a case where #51830 might help us out, depending on how it was done.
@mbohlool do query parameters show up in OpenAPI? Maybe we can examine them to decide.
Antoine Pelisse
@mbohlool do query parameters show up in OpenAPI? Maybe we can examine them to decide.
Answering on his behalf: Yes, we do have them, so I guess we can find a way around it.
"/api/v1/pods": {
"get": {
"description": "list or watch objects of kind Pod",
"consumes": [
"*/*"
],
"produces": [
"application/json",
"application/yaml",
"application/vnd.kubernetes.protobuf",
"application/json;stream=watch",
"application/vnd.kubernetes.protobuf;stream=watch"
],
"schemes": [
"https"
],
"tags": [
"core_v1"
],
"operationId": "listCoreV1PodForAllNamespaces",
"responses": {
"200": {
"description": "OK",
"schema": {
"$ref": "#/definitions/io.k8s.api.core.v1.PodList"
}
},
"401": {
"description": "Unauthorized"
}
},
"x-kubernetes-action": "list",
"x-kubernetes-group-version-kind": {
"group": "",
"kind": "Pod",
"version": "v1"
}
},
"parameters": [
{
"uniqueItems": true,
"type": "string",
"description": "The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server the server will respond with a 410 ResourceExpired error indicating the client must restart their list without the continue field. This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.",
"name": "continue",
"in": "query"
},
{
"uniqueItems": true,
"type": "string",
"description": "A selector to restrict the list of returned objects by their fields. Defaults to everything.",
"name": "fieldSelector",
"in": "query"
},
{
"uniqueItems": true,
"type": "boolean",
"description": "If true, partially initialized resources are included in the response.",
"name": "includeUninitialized",
"in": "query"
},
{
"uniqueItems": true,
"type": "string",
"description": "A selector to restrict the list of returned objects by their labels. Defaults to everything.",
"name": "labelSelector",
"in": "query"
},
{
"uniqueItems": true,
"type": "integer",
"description": "limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true.\n\nThe server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.",
"name": "limit",
"in": "query"
},
{
"uniqueItems": true,
"type": "string",
"description": "If 'true', then the output is pretty printed.",
"name": "pretty",
"in": "query"
},
{
"uniqueItems": true,
"type": "string",
"description": "When specified with a watch call, shows changes that occur after that particular version of a resource. Defaults to changes from the beginning of history. When specified for list: - if unset, then the result is returned from remote storage based on quorum-read flag; - if it's 0, then we simply return what we currently have in cache, no guarantee; - if set to non zero, then the result is at least as fresh as given rv.",
"name": "resourceVersion",
"in": "query"
},
{
"uniqueItems": true,
"type": "integer",
"description": "Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.",
"name": "timeoutSeconds",
"in": "query"
},
{
"uniqueItems": true,
"type": "boolean",
"description": "Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.",
"name": "watch",
"in": "query"
}
]
},
Daniel Smith
aggregator to interpret this query parameter?
On Mon, May 14, 2018 at 2:34 PM Antoine Pelisse <notifi...@github.com>
wrote:
> @mbohlool <https://github.com/mbohlool> do query parameters show up in
> Reply to this email directly, view it on GitHub
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAnglnHkCz_UfwLOkyLgUQs6YT7i2nYDks5tyfhSgaJpZM4T3cSY>
> .
Brian Grant
See also #11488
fejta-bot
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
fejta-bot
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
Antoine Pelisse
Closed #63559.
Antoine Pelisse
I think we can call this done. Closing.