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 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/CA%2BnsWgy6gTMq3WJsKddeti0%3DKQ_HrUxBzO8wVT78nVX0cTguGA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to