Fix command descriptions to match new cluster validation behavior

cmd/kops/rollingupdatecluster.go

@@ -52,7 +52,7 @@ var (
 
 	If rolling-update does not report that the cluster needs to be rolled, you can force the cluster to be
 	rolled with the force flag.  Rolling update drains and validates the cluster by default.  A cluster is
-	deemed validated when all required nodes are running and all pods in the kube-system namespace are operational.
+	deemed validated when all required nodes are running and all pods with a critical priority are operational.
 	When a node is deleted, rolling-update sleeps the interval for the node type, and then tries for the same period
 	of time for the cluster to be validated.  For instance, setting --master-interval=3m causes rolling-update
 	to wait for 3 minutes after a master is rolled, and another 3 minutes for the cluster to stabilize and pass

cmd/kops/validate.go

@@ -32,7 +32,7 @@ var (
 	1. All k8s masters are running and have "Ready" status.
 	2. All k8s nodes are running and have "Ready" status.
 	3. Component status returns healthy for all components.
-	4. All pods in the kube-system namespace are running and healthy.
+	4. All pods with a critical priority are running and healthy.
 	`))
 
 	validateExample = templates.Examples(i18n.T(`

docs/cli/kops_rolling-update.md

@@ -15,7 +15,7 @@ To perform a rolling update, you need to update the cloud resources first with t
 
 If rolling-update does not report that the cluster needs to be rolled, you can force the cluster to be
 rolled with the force flag.  Rolling update drains and validates the cluster by default.  A cluster is
-deemed validated when all required nodes are running and all pods in the kube-system namespace are operational.
+deemed validated when all required nodes are running and all pods with a critical priority are operational.
 When a node is deleted, rolling-update sleeps the interval for the node type, and then tries for the same period
 of time for the cluster to be validated.  For instance, setting --master-interval=3m causes rolling-update
 to wait for 3 minutes after a master is rolled, and another 3 minutes for the cluster to stabilize and pass

docs/cli/kops_rolling-update_cluster.md

@@ -15,7 +15,7 @@ To perform a rolling update, you need to update the cloud resources first with t
 
 If rolling-update does not report that the cluster needs to be rolled, you can force the cluster to be
 rolled with the force flag.  Rolling update drains and validates the cluster by default.  A cluster is
-deemed validated when all required nodes are running and all pods in the kube-system namespace are operational.
+deemed validated when all required nodes are running and all pods with a critical priority are operational.
 When a node is deleted, rolling-update sleeps the interval for the node type, and then tries for the same period
 of time for the cluster to be validated.  For instance, setting --master-interval=3m causes rolling-update
 to wait for 3 minutes after a master is rolled, and another 3 minutes for the cluster to stabilize and pass

docs/cli/kops_validate.md

@@ -12,7 +12,7 @@ This commands validates the following components:
   1.  All k8s masters are running and have "Ready" status.
   2.  All k8s nodes are running and have "Ready" status.
   3.  Component status returns healthy for all components.
-  4.  All pods in the kube-system namespace are running and healthy.
+  4.  All pods with a critical priority are running and healthy.
 
 ### Examples
 

docs/cli/kops_validate_cluster.md

@@ -12,7 +12,7 @@ This commands validates the following components:
   1.  All k8s masters are running and have "Ready" status.
   2.  All k8s nodes are running and have "Ready" status.
   3.  Component status returns healthy for all components.
-  4.  All pods in the kube-system namespace are running and healthy.
+  4.  All pods with a critical priority are running and healthy.
 
 ```
 kops validate cluster [flags]