Dongluo Chen

> On which node are the service replicas "Allocated" as listed but not Running @dvohra when a task from a replicated service is in `Allocated` state, it has not been...

It's because `update` has not finished. ``` "UpdateStatus": { "State": "updating", "StartedAt": "2017-02-01T21:30:48.294165833Z", "CompletedAt": "1970-01-01T00:00:00Z", "Message": "update in progress" } ``` I think it better to fail this update with...

In my test on current Docker master (1.14.0-dev), the update only takes down `Parallelism` (default to 1) replicas, which protects the service from failing. Multiple constraints apply as "&&". In...

@dvohra that's correct. If you put these constraints on service create, no instance would advance to `running`.

> Shouldn't update be the same. At least have some consistency. `Update` is different from initial service create. The reason is `update` should try to protect service from failure. In...

`service create` don't need timeout because it doesn't need to stop. I think `service update` might need one. ``` ~$ docker service inspect redis --pretty ID: yg1ar0a3s1j71i3gd0fx869h7 Name: redis Service...

@aaronlehmann @aluzzardi What do you think of update that stuck at `Pending` (previously `Allocated`)? I think we should fail the update, either with number of retries or timeout. I think...

@dvohra When constraints are changed, it starts a new update which overwrites previous update. @aaronlehmann Agree with the optional timeout setting.

Docker swarm mode runs on top of VM or physical machine. It does not track the reason of VM failure/reboot. It tracks the connectivity change. ``` ubuntu@ip-172-19-241-146:~$ docker node inspect...

By default swarm mode keeps 5 copies of a task instance. You can see the failure history using `docker service ps SERVICE`. ``` ubuntu@ip-172-19-241-145:~$ docker service ps ctest ID NAME...