KEP-127: Address more review comments

Signed-off-by: Rodrigo Campos <[email protected]>

Author: rata

keps/sig-node/127-user-namespaces/README.md

@@ -630,6 +630,8 @@ use container runtime versions that have the needed changes.
 
 - Gather and address feedback from the community
 - Be able to configure UID/GID ranges to use for pods
+- Add unit tests that exercise the feature gate switch (see section "Are there
+any tests for feature enablement/disablement?")
 - This feature is not supported on Windows.
 - Get review from VM container runtimes maintainers (not blocker, as VM runtimes should just ignore
   the field, but nice to have)
@@ -670,6 +672,26 @@ enhancement:
   CRI or CNI may require updating that component before the kubelet.
 -->
 
+#### Kubelet and Kube-apiserver skew
+
+The apiserver and kubelet feature gate enablement work fine in any combination:
+
+1. If the apiserver has the feature gate enabled and the kubelet doesn't, then the pod will show that
+   field and the kubelet will ignore it. Ultimately, the pod is created without user namespaces.
+2. If the apiserver has the feature gate disabled and the kubelet has the flag enabled, then the pod
+   won't show this field and therefore the kubelet won't act on a field that isn't shown. The pod is
+   created with the feature gate disabled.
+
+The kubelet can still create pods with user namespaces if static-pods are configured with
+pod.spec.hostUsers and has the feature gate enabled.
+
+If the kube-apiserver doesn't support the feature at all (< 1.25), a pod with userns will be
+rejected.
+
+If the kubelet doesn't support the feature (< 1.25), it will ignore the pod.spec.hostUsers field.
+
+#### Kubelet and container runtime skews
+
 Some definitions first:
 - New kubelet: kubelet with CRI proto files that includes the changes proposed in
 this KEP.
@@ -794,6 +816,9 @@ We will also unit test that, if pods were created with the new field
 pod.specHostUsers, then if the featuregate is disabled all works as expected (no
 user namespace is used).
 
+We will add tests exercising the `switch` of feature gate itself (what happens
+if I disable a feature gate after having objects written with the new field)
+
 <!--
 The e2e framework does not currently support enabling or disabling feature
 gates. However, unit tests in each component dealing with managing data, created
@@ -815,16 +840,17 @@ This section must be completed when targeting beta to a release.
 
 ###### How can a rollout or rollback fail? Can it impact already running workloads?
 
-The rollout is just a feature flag on the kubelet and the kube-apiserver.
+If one APIserver is upgraded while other's aren't and you are talking to a not
+upgraded the pod will be accepted (if the apiserver is >= 1.25). 
 
-If one APIserver is upgraded while other's aren't and you are talking to a not upgraded the pod
-will be accepted (if the apiserver is >= 1.25). If it is scheduled to a node that the kubelet has
-the feature flag activated and the node meets the requirements to use user namespaces, then the
-pod will be created with the namespace. If it is scheduled to a node that has the feature disabled,
-it will be created without the user namespace.
+If it is scheduled to a node where the kubelet has the feature flag activated and
+the node meets the requirements to use user namespaces, then the pod will be
+created with the namespace. If it is scheduled to a node that has the feature
+disabled, it will be created without the user namespace.
 
-On a rollback, pods created while the feature was active (created with user namespaces) will have to
-be re-created without user namespaces.
+On a rollback, pods created while the feature was active (created with user namespaces) will
+have to be re-created without user namespaces. If those weren't recreated, they will continue
+to run in user namespace.
 
 <!--
 Try to be as paranoid as possible - e.g., what if some components will restart