Merge remote-tracking branch 'upstream/master' into merged-master-dev-1.16

content/en/docs/reference/access-authn-authz/webhook.md

@@ -108,7 +108,13 @@ the request and respond to either allow or disallow access. The response body's
 }
 ```
 
-To disallow access, the remote service would return:
+For disallowing access there are two methods.
+
+The first method is preferred in most cases, and indicates the authorization
+webhook does not allow, or has "no opinion" about the request, but if other 
+authorizers are configured, they are given a chance to allow the request. 
+If there are no other authorizers, or none of them allow the request, the 
+request is forbidden. The webhook would return:
 
 ```json
 {
@@ -121,6 +127,23 @@ To disallow access, the remote service would return:
 }
 ```
 
+The second method denies immediately, short-circuiting evaluation by other 
+configured authorizers. This should only be used by webhooks that have 
+detailed knowledge of the full authorizer configuration of the cluster. 
+The webhook would return:
+
+```json
+{
+  "apiVersion": "authorization.k8s.io/v1beta1",
+  "kind": "SubjectAccessReview",
+  "status": {
+    "allowed": false,
+    "denied": true,
+    "reason": "user does not have read access to the namespace"
+  }
+}
+```
+
 Access to non-resource paths are sent as:
 
 ```json

content/en/docs/reference/glossary/qos-class.md

@@ -15,7 +15,7 @@ related:
  - pod
 
 ---
- QoS Class (Quality of Service Class)) provides a way for Kubernetes to classify Pods within the cluster into several classes and make decisions about scheduling and eviction.
+ QoS Class (Quality of Service Class) provides a way for Kubernetes to classify Pods within the cluster into several classes and make decisions about scheduling and eviction.
 
 <!--more--> 
 QoS Class of a Pod is set at creation time  based on its compute resources requests and limits settings. QoS classes are used to make decisions about Pods scheduling and eviction.

content/en/docs/reference/kubectl/cheatsheet.md

@@ -205,9 +205,12 @@ As of version 1.11 `rolling-update` have been deprecated (see [CHANGELOG-1.11.md
 
 ```bash
 kubectl set image deployment/frontend www=image:v2               # Rolling update "www" containers of "frontend" deployment, updating the image
+kubectl rollout history deployment/frontend                      # Check the history of deployments including the revision 
 kubectl rollout undo deployment/frontend                         # Rollback to the previous deployment
+kubectl rollout undo deployment/frontend --to-revision=2         # Rollback to a specific revision
 kubectl rollout status -w deployment/frontend                    # Watch rolling update status of "frontend" deployment until completion
 
+
 # deprecated starting version 1.11
 kubectl rolling-update frontend-v1 -f frontend-v2.json           # (deprecated) Rolling update pods of frontend-v1
 kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2  # (deprecated) Change the name of the resource and update the image

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

@@ -452,3 +452,26 @@ Another difference is that an applier using Client Side Apply is unable to chang
 ### Custom Resources
 
 Server Side Apply currently treats all custom resources as unstructured data. All keys are treated the same as struct fields, and all lists are considered atomic. In the future, it will use the validation field in Custom Resource Definitions to allow Custom Resource authors to define how to how to merge their own objects.
+
+### Clearing ManagedFields
+
+It is possible to strip all managedFields from an object by overwriting them using `MergePatch`, `StrategicMergePatch`, `JSONPatch` or `Update`, so every non-apply operation.
+This can be done by overwriting the managedFields field with an empty entry. Two examples are:
+
+```json
+PATCH /api/v1/namespaces/default/configmaps/example-cm
+Content-Type: application/merge-patch+json
+Accept: application/json
+Data: {"metadata":{"managedFields": [{}]}}
+```
+
+```json
+PATCH /api/v1/namespaces/default/configmaps/example-cm
+Content-Type: application/json-patch+json
+Accept: application/json
+Data: [{"op": "replace", "path": "/metadata/managedFields", "value": [{}]}]
+```
+
+This will overwrite the managedFields with a list containing a single empty entry that then results in the managedFields being stripped entirely from the object. Note that just setting the managedFields to an empty list will not reset the field. This is on purpose, so managedFields never get stripped by clients not aware of the field.
+
+In cases where the reset operation is combined with changes to other fields than the managedFields, this will result in the managedFields being reset first and the other changes being processed afterwards. As a result the applier takes ownership of any fields updated in the same request.