Conditional Handlers

Archives Ansible Project
1

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?
2

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

3

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) :slight_smile:

4

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.

5

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.

6

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:

7

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
8

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.