whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Document server-side dry-run is GA in 1.18 (#19549)

Browse Source 
* Update dry-run docs.

* Promote server-side dry-run feature state to stable in 1.18
* Replace --dry-run with --dry-run=server|client|none accordingly
* Update server-side dry-run blog post

* Update content/en/docs/reference/using-api/api-concepts.md

Co-Authored-By: Tim Bannister <tim@scalefactory.com>

* Address comments

* Add note at end of server-side dry-run blogpost

Co-authored-by: Tim Bannister <tim@scalefactory.com>
This commit is contained in:
Julian V. Modesto
2020-03-12 16:02:39 -04:00
committed by GitHub
parent 99052a4610
commit 601b104f9b
7 changed files with 19 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/reference/using-api/api-concepts.md
+4 -2
View File
@@ -336,12 +336,14 @@ Once the last finalizer is removed, the resource is actually removed from etcd.
## Dry-run
{{< feature-state for_k8s_version="v1.13" state="beta" >}} In version 1.13, the dry-run beta feature is enabled by default. The modifying verbs (`POST`, `PUT`, `PATCH`, and `DELETE`) can accept requests in a dry-run mode. DryRun mode helps to evaluate a request through the typical request stages (admission chain, validation, merge conflicts) up until persisting objects to storage. The response body for the request is as close as possible to a non-dry-run response. The system guarantees that dry-run requests will not be persisted in storage or have any other side effects.
{{< feature-state for_k8s_version="v1.18" state="stable" >}}
The modifying verbs (`POST`, `PUT`, `PATCH`, and `DELETE`) can accept requests in a _dry run_ mode. Dry run mode helps to evaluate a request through the typical request stages (admission chain, validation, merge conflicts) up until persisting objects to storage. The response body for the request is as close as possible to a non-dry-run response. The system guarantees that dry-run requests will not be persisted in storage or have any other side effects.
### Make a dry-run request
Dry-run is triggered by setting the `dryRun` query parameter. This parameter is a string, working as an enum, and in 1.13 the only accepted values are:
Dry-run is triggered by setting the `dryRun` query parameter. This parameter is a string, working as an enum, and the only accepted values are:
* `All`: Every stage runs as normal, except for the final storage stage. Admission controllers are run to check that the request is valid, mutating controllers mutate the request, merge is performed on `PATCH`, fields are defaulted, and schema validation occurs. The changes are not persisted to the underlying storage, but the final object which would have been persisted is still returned to the user, along with the normal status code. If the request would trigger an admission controller which would have side effects, the request will be failed rather than risk an unwanted side effect. All built in admission control plugins support dry-run. Additionally, admission webhooks can declare in their [configuration object](/docs/reference/generated/kubernetes-api/v1.13/#webhook-v1beta1-admissionregistration-k8s-io) that they do not have side effects by setting the sideEffects field to "None". If a webhook actually does have side effects, then the sideEffects field should be set to "NoneOnDryRun", and the webhook should also be modified to understand the `DryRun` field in AdmissionReview, and prevent side effects on dry-run requests.
* Leave the value empty, which is also the default: Keep the default modifying behavior.