On Mon, Sep 29, 2014 at 1:53 PM, Jazzed <[email protected]> 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/CAG9juEo3qsT0xze%2B78gneE0pVeS-xNUpyLqnVB9NCxJAduWdKA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
