Thanks for that explanation, Toshio. That helps things a lot. And thanks for tracing through the code too!
If this is just a bug, then a fix would be nice. What I was hoping for is for the docker module to detect a new version is available. Then I could do a dry-run and check if any of my docker applications can be upgraded by looking at the ansible output. On Monday, September 29, 2014 3:22:28 PM UTC-7, tkuratomi wrote: > > On Mon, Sep 29, 2014 at 1:53 PM, Jazzed <[email protected] > <javascript:>> wrote: > >>> > >> Assuming that: > >> 1) The kill old container task isn't supposed to be present in the > second > >> example > >> 2) The snazzy/cyweb container is running a long running process > >> 3) Manually running docker's tools does something similar > >> > >> I think this behaviour is intended. > >> > >> This seems like we're just asking the docker module to guarantee that > the > >> service is running. Not to restart the service. I think we need to be > >> explicit here that we aren't just saying "ensure service is running" > but are > >> actually saying "restart the service, picking up a new version if > that's > >> deployed". > >> > >> -Toshio > > > > > > Sorry I'm slow to understand Ansible. But the docker module is suppose > to > > guarantee that the service is running, correct. Shouldn't it ensure that > the > > VERSION of the service I specify in the playbook is running? > > > > How does ansible handle this for other applications besides docker? I > will > > need to go look at that. Won't ansible let me say I want "version 1.0 of > > clock app", "version 1.5 of snogger app". And if the server has ".09 of > > clock app" and "1.0 of snogger app", it should change them to the new > > version, correct? > > > Conceptually, containers seem somewhere between applications and > hosts. Within the application case, let's think about services in > particular. You can specify to a module like yum to update a package > to a specific version. However, ansible doesn't ensure that the > service that is shipped with that package is restarted after the > update. Most of the time the package system itself will do that but > sometimes it won't (For instance, if the updated service needs new > data [changed config file format or old user entered data] and no > automatic data conversion is possible). In the latter case, you'd > have to specify a restart as a separate ansible task. > > For hosts, a restart is definitely a separate task from an update. > You might install a new kernel version immediately upon release but > not want to restart the server until a scheduled outage window, for > instance. > > Since it sounds like using docker manually would also require you to > first specify that the old container is shutdown and then that the new > container is created, I think that we probably want the same behaviour > from the ansible docker module (although we could have another > parameter that tells ansible to restart the container as well). > > OTOH, I missed the fact that you had specified name in your playbook > before. Tracing through the code when that's specified, it looks like > the present code wants to destroy the old container and crate a new > one in that case; it's just buggy because it relies on the image's > symbolic name (which can be changed to reference a different image) > instead of its id. > > So now I'm not sure if we should just fix this bug and then implement > a parameter that says "Do not restart the running container"... > > -Toshio > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/513c5e63-2628-42f7-bede-df49d061ae33%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
