> The when on the flush is actually a bit redundant You're right, I failed to explain that. The only motivation for having the when statement is to prevent unnecessary early flushing. Your when statement in the service as a task is also nice and simple solution.
Anders On 8 June 2014 17:28, Michael DeHaan <[email protected]> wrote: > The when on the flush is actually a bit redundant, as if you are trying to > not run extra steps, and nothing else is notified, there will be nothing to > run. > > So you could just have a task. > > - service: name=foo state=restarted enabled=yes > when: installation|changed > > OR go ahead and flush the handlers without the when statement > > - meta: flush_handlers > > > > On Sun, Jun 8, 2014 at 5:55 AM, Anders Ingemann <[email protected]> > wrote: > >> Sorry for resurrecting an old thread, but it ranks high on the search >> results when I googled "ansible conditional handlers", so I thought I might >> post my solution here for others to find. I had the same challenge and it >> wasn't really more than a nuisance, but I'm sometimes a perfectionist that >> way. >> What you can do is flush the handlers before running the "start" task, >> this way it will be a noop (except for the enabling part) and everything is >> good. >> You can even skip the flushing if it is not the first installation and >> avoid early restarts, by registering a variable like so: >> >> - name: install myservice >> apt: pkg=myservice state=present >> sudo: yes >> register: installation >> >> >> - name: trigger myservice restart >> meta: flush_handlers >> when: installation|changed >> >> - name: start myservice >> service: name=myservice state=started enabled=yes >> sudo: yes >> >> >> >> On Friday, October 4, 2013 5:17:47 PM UTC+2, Casey Huggins wrote: >>> >>> Thanks all. Michael, I think I agree with you--if the service is not >>> running, I want Ansible to rectify that whenever it runs. Relying on the >>> restart notify seems like a risk in that regard. I guess I will just deal >>> with the extra time. >>> >>> >>> >>> On Friday, October 4, 2013 6:38:15 AM UTC-7, Michael DeHaan wrote: >>>> >>>> BTW, here's why people should not do this. >>>> >>>> Someone stops your service, nothing else changes, or your service just >>>> fails. >>>> >>>> You want to re-run the playbook to make sure your configuration is >>>> properly applied without knowing what happened to the remote system. >>>> >>>> In this case, you absolutely want to make sure your service is running >>>> in that step and wouldn't want to take it off. >>>> >>>> In this case, if your service init script already makes sure the >>>> service is running too (it might), you could just remove the notify from >>>> the package step. >>>> But you should always have the notify on the config step. >>>> >>>> So, really, I'd enjoy that 20 seconds if you want to periodic >>>> configuration re-application, if not, you could optimize. >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Oct 4, 2013 at 9:27 AM, Michael DeHaan <[email protected] >>>> > wrote: >>>> >>>>> Seems like in your case you would be welcome to just have: >>>>> >>>>> - name: ensure myservice is running >>>>> service: name= myservice enabled=yes >>>>> >>>>> (just having the enabled part) >>>>> >>>>> Though I'd use that 20 seconds to reload some xkcd or go to the >>>>> breakroom and enjoy a beverage (very very very quickly) :) >>>>> >>>>> >>>>> >>>>> On Fri, Oct 4, 2013 at 9:14 AM, John Jarvis <[email protected]> wrote: >>>>> >>>>>> For the case where you are installing a new node do you need: >>>>>> >>>>>> - name: ensure myservice is running >>>>>> service: name= myservice state=running enabled=yes >>>>>> >>>>>> ? >>>>>> >>>>>> Maybe there is more context here but it seems like the notify will >>>>>> cover the case where the service isn't running and you need to start it >>>>>> up >>>>>> on a fresh install. >>>>>> -John >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Oct 3, 2013 at 9:41 PM, Casey Huggins <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Forgive me if this is covered in the documentation, but I was unable >>>>>>> something that seemed like it would handle my use case. I have the >>>>>>> following in my tasks file: >>>>>>> >>>>>>> - name: verify myservice is installed >>>>>>> yum: pkg=myservice-1.2.3 state=installed >>>>>>> notify: >>>>>>> - restart myservice >>>>>>> >>>>>>> - name: ensure myservice is running >>>>>>> service: name= myservice state=running enabled=yes >>>>>>> >>>>>>> This works great for scenario where I am upgrading an existing >>>>>>> node--I simply change myservice-1.2.3 to myservice-1.2.4, and ansible >>>>>>> will >>>>>>> install the new package, and notify the restart. >>>>>>> >>>>>>> However, it is a little clunky for the case where I am installing on >>>>>>> a new node. Then, when I run the playbook, ansible will: >>>>>>> >>>>>>> >>>>>>> 1. Install myservice-1.2.3 >>>>>>> 2. start the service >>>>>>> 3. restart the service >>>>>>> >>>>>>> The service itself is complex, and the starts can take upwards of 20 >>>>>>> seconds. This makes installs a slow and unwieldy. Is there a way I can >>>>>>> specify that the restart should not happen on first install? Or is >>>>>>> there a >>>>>>> better way to go about this? >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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]. >>>>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>>>> >>>>>> >>>>>> -- >>>>>> 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]. >>>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Michael DeHaan <[email protected]> >>>>> CTO, AnsibleWorks, Inc. >>>>> http://www.ansibleworks.com/ >>>>> >>>>> >>>> >>>> >>>> -- >>>> Michael DeHaan <[email protected]> >>>> CTO, AnsibleWorks, Inc. >>>> http://www.ansibleworks.com/ >>>> >>>> -- >> 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/7964891a-b512-4dba-ae8d-663754b43c82%40googlegroups.com >> <https://groups.google.com/d/msgid/ansible-project/7964891a-b512-4dba-ae8d-663754b43c82%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Ansible Project" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/ansible-project/Aiz6ofeigq4/unsubscribe. > To unsubscribe from this group and all its topics, 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/CA%2BnsWgy6gTMq3WJsKddeti0%3DKQ_HrUxBzO8wVT78nVX0cTguGA%40mail.gmail.com > <https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgy6gTMq3WJsKddeti0%3DKQ_HrUxBzO8wVT78nVX0cTguGA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAMcOGXGZbH%3D6_M%3D3OzK0PgUq04Zc4TBXLJwCa%3DdVT8AxjD7iLA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
