Closed hamsterksu closed 9 years ago
@chuckbutler in the tasks name: set subnet daemon option and name: set subnet daemon option we override existing docker settings. if we change docker start parameters we should restart it.
Also according to the docs: http://docs.ansible.com/ansible/playbooks_intro.html
we can fire duplicate events:
"These ‘notify’ actions are triggered at the end of each block of tasks in a playbook, and will only be triggered once even if notified by multiple different tasks."
order of handlers declarations are important.
"Notify handlers are always run in the order written"
additional information - http://docs.ansible.com/ansible/glossary.html#notify
"The act of a task registering a change event and informing a handler task that another action needs to be run at the end of the play. If a handler is notified by multiple tasks, it will still be run only once. Handlers are run in the order they are listed, not in the order that they are notified."
I did some reading on Ansible this weekend in follow up to your post, and this was highly insightful in clearing up some misconceptions I had about Ansible Handlers. Thanks for the contributions @hamsterksu
I'm going to +1 and merge this
@hamsterksu moving the handler lower in the playbook doesn't appear to have any real function other than organization. Was this more for readability or was there another purpose for this?
I'm OK with cycling docker, but ideally we should only be recycling the daemon once the DOCKEROPTS file has been fully fleshed out with whatever options are required. I think its better to add another play at the end of config-changed run to do so. What we want to try to do here is mitigate restarting docker arbitrarily as any config updates, if they dont directly modify the runtime of docker or update the daemon, it seems heavy fisted to recycle the containers.
I'm open to a re-interpretation of this PR where its less cycling and disruptive of running workloads.