Immediate notifies?

Archives Ansible Project
1

I'm writing a bunch of tasks and playbooks to bring up new VM nodes:

1) installing postfix
2) modifying /etc/postfix/main.cf to configuring it as a satellite
    a) register a handler to restart postfix
3) install apt-listchanges
4) apt-get update
5) apt-get -y dist-upgrade

However, it's only after 5 does the postfix handler fire, so the email that apt-listchanges sends goes to /var/mail/root instead of me. So I'm now using:

- name: write /etc/aliases to forward all email to me.
   action: lineinfile dest=/etc/aliases regexp="^root:.*" line=root:blair@orcaware.com backup=yes
   register: last_result

- name: rebuild /etc/aliases.db
   action: command /usr/bin/newaliases
   only_if: '${last_result.changed}'

Is there an idiom for notify that we can use an immediate notify to fire the handler then instead of writing register and only_if? Is there an 'immediate_notify'?

Blair

2

There is nothing better than what you have, well, "when_boolean" is
better, but I would like to make this more idiomatic

Some sort of syntactic sugar where you give it the name of the task
could be interesting

- name: name of task
  action: foo

- name: name of notifier
  when_changed: name of task

In this case, we would, however, have to register the result of every
single task automagically. Eats a bit more memory. Maybe we don't
care.

Thoughts? (Daniel? Stephen? others?)

3

If we are only interested in the last task, maybe we register that automatically?
Then last_task gets overwritten on each task.

  • name: name of task
    action: foo

  • name: name of notifier
    when_changed: $last_task

4

We used to register $last_result exactly like this.

I think I'm fine with reinstating it.

5

On Ansible’s Devel branch you should also be able to use
when_changed: $last_result
instead of
only_if: ‘${last_result.changed}’

6

I just tried using this with the most current devel branch and it didn’t work as expected. I had to manually register last_result for it to work, but also there is an inherent issue in this. If the task you want the last result from is skipped (in the case of using command and the creates attribute), you do not get a last_result variable set. Perhaps instead of having the command module skip the task it should register it with “ok”?

Any thoughts?

Thanks,

Andrew

7

Sorry, what I meant was the last_result should be registered with no change instead of the last_result variable not existing.

Thanks,

Andrew

8

lsat_result does have to be manually registered, this is still true

register on skipped is a known issue we have to fix for sure

9

Ok, cool. Thanks Michael, loving Ansible!

10

Andrew,

A work around that worked for me is to declare the variable with a value of zero, so when the task is skipped, it behaves as if the tasks had not run or failed. Look at this thread:

https://groups.google.com/forum/?fromgroups=#!topic/ansible-project/02Hl4WzRzD0

11

Why not just use multiple plays.

The first play does the postfix stuff and has a handler at the end of that play.

The second play does the upgrades, etc

Afaik - handlers get run at the end of each play, right?

-sv

12

Cool, I’ll use this workaround for now. Thanks!

13

Afaik - handlers get run at the end of each play, right?

Yes!