summaryrefslogtreecommitdiff
path: root/simple-rolling-update.md
diff options
context:
space:
mode:
authorRichieEscarez <rescarez@google.com>2015-06-16 14:48:51 -0700
committerRichieEscarez <rescarez@google.com>2015-06-17 08:48:59 -0700
commit9e35c48d4abfa4b1bae2b4ed3a81047d6604985e (patch)
tree1eb0b3fc2003558004f88d3ad05cfe7c29a94b62 /simple-rolling-update.md
parenta407b64a3d2be8e3ddca9192609c72e92b64a6a9 (diff)
Qualified all references to "controller" so that references to "replication controller" are clear. fixes #9404
Also ran hacks/run-gendocs.sh
Diffstat (limited to 'simple-rolling-update.md')
-rw-r--r--simple-rolling-update.md14
1 files changed, 7 insertions, 7 deletions
diff --git a/simple-rolling-update.md b/simple-rolling-update.md
index e5b47d98..0208b609 100644
--- a/simple-rolling-update.md
+++ b/simple-rolling-update.md
@@ -8,20 +8,20 @@ Assume that we have a current replication controller named ```foo``` and it is r
```kubectl rolling-update rc foo [foo-v2] --image=myimage:v2```
-If the user doesn't specify a name for the 'next' controller, then the 'next' controller is renamed to
-the name of the original controller.
+If the user doesn't specify a name for the 'next' replication controller, then the 'next' replication controller is renamed to
+the name of the original replication controller.
Obviously there is a race here, where if you kill the client between delete foo, and creating the new version of 'foo' you might be surprised about what is there, but I think that's ok.
See [Recovery](#recovery) below
-If the user does specify a name for the 'next' controller, then the 'next' controller is retained with its existing name,
-and the old 'foo' controller is deleted. For the purposes of the rollout, we add a unique-ifying label ```kubernetes.io/deployment``` to both the ```foo``` and ```foo-next``` controllers.
-The value of that label is the hash of the complete JSON representation of the```foo-next``` or```foo``` controller. The name of this label can be overridden by the user with the ```--deployment-label-key``` flag.
+If the user does specify a name for the 'next' replication controller, then the 'next' replication controller is retained with its existing name,
+and the old 'foo' replication controller is deleted. For the purposes of the rollout, we add a unique-ifying label ```kubernetes.io/deployment``` to both the ```foo``` and ```foo-next``` replication controllers.
+The value of that label is the hash of the complete JSON representation of the```foo-next``` or```foo``` replication controller. The name of this label can be overridden by the user with the ```--deployment-label-key``` flag.
#### Recovery
If a rollout fails or is terminated in the middle, it is important that the user be able to resume the roll out.
-To facilitate recovery in the case of a crash of the updating process itself, we add the following annotations to each replicaController in the ```kubernetes.io/``` annotation namespace:
- * ```desired-replicas``` The desired number of replicas for this controller (either N or zero)
+To facilitate recovery in the case of a crash of the updating process itself, we add the following annotations to each replication controller in the ```kubernetes.io/``` annotation namespace:
+ * ```desired-replicas``` The desired number of replicas for this replication controller (either N or zero)
* ```update-partner``` A pointer to the replication controller resource that is the other half of this update (syntax ```<name>``` the namespace is assumed to be identical to the namespace of this replication controller.)
Recovery is achieved by issuing the same command again: