Suggest a simple rolling update. #6713

brendandburns · 2015-04-10T23:11:33Z

@bgrant0607 @kelseyhightower @jlowdermilk @davidopp @smarterclayton

brendandburns · 2015-04-10T23:11:47Z

j3ffml · 2015-04-10T23:26:03Z

docs/design/simple-rolling-update.md

+   * Do the standard down/up one-by-one until foo has replicas zero and foo-next has replicas N
+   * delete rc foo
+   * create rc foo that is identical to foo-next
+   * delete foo-next


This will require us changing the validation rules for rc. Currently we block rc creation if the selector is a sub/superset of an existing rc selector. We'd need to change it so that validation allows duplicate rcs with overlapping selectors if they have the same desired size.

We should just delete both controllers first. Nothing good can come from having 2 controlling the same set of pods at the same time.

What happens if the server dies somewhere during this multi-stage process? Do we require the client to detect this and finish the remaining operations when the server comes back up? Can we use annotations to help with this, like we're currently using annotations with kubectl rollingupdate?

@bgrant0607
I would really prefer not to leave a user in a situation where their pods are unmanaged, so my preference would be to update the validation rules as @jlowdermilk suggests.

I'd much rather have 2 replication controllers temporarily controlling the same pods, than temporarily have no replication controllers controlling the pods.

Especially if we add validation so that you really can't resize them.

@davidopp
Added some details on annotations.

Ok. This is an implementation detail. We can always change it later if it causes problems.

bgrant0607 · 2015-04-11T00:24:16Z

docs/design/simple-rolling-update.md

+### Lightweight rollout
+Assume that we have a current replication controller named ```foo``` and it is running image ```image:v1```
+
+```kubectl rollingupdate rc foo --image=myimage:v2```


BTW, it's rolling-update now. rollingupdate is deprecated.

bgrant0607 · 2015-04-11T00:28:35Z

cc @rjnagal

bgrant0607 · 2015-04-11T00:32:41Z

docs/design/simple-rolling-update.md

+This is a lightweight design document for simple rolling update in ```kubectl```
+
+### Lightweight rollout
+Assume that we have a current replication controller named ```foo``` and it is running image ```image:v1```


This assumes a single container, obviously.

As much as possible, flags should match kubectl run/run-container.

If we were to support multiple containers in run, we would support that here, also.

I'm ok if the multi-container case requires a config file. I think this will hit the 80% use case pretty squarely.

Fair enough.

brendandburns · 2015-04-11T03:29:43Z

Comments addressed. ptal.

Thanks
--brendan

bgrant0607 · 2015-04-11T03:48:04Z

docs/design/simple-rolling-update.md

+   * ```desired-replicas``` The desired number of replicas for this controller (either N or zero)
+   * ```update-partner``` A pointer to the resource that is the other half of this update (syntax ```<namespace>:<id>```)
+
+Recovery is achieved by issuing the 'resume' rolling update command:


Why can't they just execute exactly the same command?

Agree - anything else is non-intuitive.

On Apr 10, 2015, at 11:48 PM, Brian Grant notifications@github.com wrote:

In docs/design/simple-rolling-update.md:

+### Aborting a rollout
+Abort is assumed to want to reverse a rollout in progress. If the rollout has completed, then rollback is just a special case of rollout.
+
+kubectl rolling-update rc foo [foo-v2] abort
+
+Under the hood this will:

* look for a replica controller named foo-next, or the user-specified name (foo-v2 in the example above)

* Given this controller it will then increment/decrement until foo is back to the initial size, and foo-next is size zero.

* When foo-next is size zero, it is deleted.

+### Recovery
+To facilitate recovery in the case of a crash of the updating process itself, we add the following annotations to each replicaController:

* desired-replicas The desired number of replicas for this controller (either N or zero)

* update-partner A pointer to the resource that is the other half of this update (syntax <namespace>:<id>)

+Recovery is achieved by issuing the 'resume' rolling update command:
Why can't they just execute exactly the same command?

—
Reply to this email directly or view it on GitHub.

brendandburns · 2015-04-21T04:08:18Z

Updated this to reflect comments and add more detail.

@smarterclayton @jlowdermilk @bgrant0607

please take a look.

Thanks!
--brendan

brendandburns · 2015-04-21T19:42:10Z

@smarterclayton @bgrant0607 friendly ping on this, I'd like to start implementing asap.

Thanks!
--brendan

davidopp · 2015-04-21T19:46:51Z

docs/design/simple-rolling-update.md

+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.
+
+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.


I think you need to explain how the rename is implemented, otherwise it's not clear what the race condition is that you're referring to.

thockin · 2015-04-21T21:11:38Z

docs/design/simple-rolling-update.md

+
+For the purposes of this example, assume that we are rolling from ```foo``` to ```foo-next``` where the only change is an image update from `v1` to `v2`
+
+#### Initialization


Can you detail what happens if the user did not specify foo-next? How do you crash-recover in this case? Where does the update-partner annotation come into play?

brendandburns · 2015-04-22T17:19:37Z

@davidopp @thockin @bgrant0607 @smarterclayton

Comments addresed. Please re-check.

Thanks!
--brendan

bgrant0607 · 2015-04-23T00:13:07Z

LGTM

davidopp · 2015-04-23T05:47:46Z

LGTM

Suggest a simple rolling update.

thockin · 2015-04-23T19:52:19Z

docs/design/simple-rolling-update.md

+### Aborting a rollout
+Abort is assumed to want to reverse a rollout in progress.
+
+```kubectl rolling-update rc foo [foo-v2] --abort```


FWIW I preferred "rollback" or "reverse" to "abort". Abort implies killing an on-going process.

Me, too, but perhaps an argument could be made that it's similar to unstaging a commit in git.

Suggest a simple rolling update.

googlebot added the cla: yes label Apr 10, 2015

j3ffml reviewed Apr 10, 2015
View reviewed changes

lavalamp assigned bgrant0607 Apr 11, 2015

bgrant0607 reviewed Apr 11, 2015
View reviewed changes

brendandburns force-pushed the docs branch 3 times, most recently from c8f3eae to 5333b7a Compare April 11, 2015 03:28

bgrant0607 reviewed Apr 11, 2015
View reviewed changes

bgrant0607 mentioned this pull request Apr 20, 2015

Add cleanup policy to RollingUpdater #6996

Merged

brendandburns force-pushed the docs branch from 5333b7a to eaf39cc Compare April 21, 2015 04:07

davidopp reviewed Apr 21, 2015
View reviewed changes

thockin reviewed Apr 21, 2015
View reviewed changes

brendandburns force-pushed the docs branch 2 times, most recently from 964c5a9 to 34d6b44 Compare April 22, 2015 17:19

Suggest a simple rolling update.

7e0f6f8

brendandburns force-pushed the docs branch from 34d6b44 to 7e0f6f8 Compare April 22, 2015 17:28

davidopp added a commit that referenced this pull request Apr 23, 2015

Merge pull request #6713 from brendandburns/docs

54f2015

Suggest a simple rolling update.

davidopp merged commit 54f2015 into kubernetes:master Apr 23, 2015

thockin reviewed Apr 23, 2015
View reviewed changes

bgrant0607 mentioned this pull request Apr 30, 2015

Rolling Updates: Add support for --rollback. #7575

Merged

xingzhou pushed a commit to xingzhou/kubernetes that referenced this pull request Dec 15, 2016

Merge pull request kubernetes#6713 from brendandburns/docs

870c24f

Suggest a simple rolling update.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Suggest a simple rolling update. #6713

Suggest a simple rolling update. #6713

brendandburns commented Apr 10, 2015

brendandburns commented Apr 10, 2015

j3ffml Apr 10, 2015

bgrant0607 Apr 11, 2015

davidopp Apr 11, 2015

brendandburns Apr 11, 2015

bgrant0607 Apr 11, 2015

bgrant0607 Apr 11, 2015

brendandburns Apr 11, 2015

bgrant0607 commented Apr 11, 2015

bgrant0607 Apr 11, 2015

brendandburns Apr 11, 2015

bgrant0607 Apr 11, 2015

brendandburns commented Apr 11, 2015

bgrant0607 Apr 11, 2015

smarterclayton Apr 11, 2015

brendandburns Apr 21, 2015

brendandburns commented Apr 21, 2015

brendandburns commented Apr 21, 2015

davidopp Apr 21, 2015

thockin Apr 21, 2015

brendandburns Apr 22, 2015

brendandburns commented Apr 22, 2015

bgrant0607 commented Apr 23, 2015

davidopp commented Apr 23, 2015

thockin Apr 23, 2015

bgrant0607 Apr 23, 2015


		For the purposes of this example, assume that we are rolling from ```foo``` to ```foo-next``` where the only change is an image update from `v1` to `v2`

		#### Initialization

Suggest a simple rolling update. #6713

Suggest a simple rolling update. #6713

Conversation

brendandburns commented Apr 10, 2015

brendandburns commented Apr 10, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bgrant0607 commented Apr 11, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

brendandburns commented Apr 11, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

brendandburns commented Apr 21, 2015

brendandburns commented Apr 21, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

brendandburns commented Apr 22, 2015

bgrant0607 commented Apr 23, 2015

davidopp commented Apr 23, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment