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. For more options, visit https://groups.google.com/d/optout.
