Hi all,
I’ve run into a situation that for me demands
an improvement to “notify” or an additional
parameter that you can attach to tasks.
e.g:
- name: Build/Install foo
action: command make install
exec: refresh ld cache
Where “refresh ld cache” is defined as:
- name: refresh ld cache
action: command /sbin/ldconfig
Basically as I understand it, notify has a
many:1 relationship meaning that no matter
how many tasks refer to a “handler”, it is
only executed once. More over, it is only
executed at the end of a play.
This works for the use-case(s) of:
- Restart services (e.g: Apache)
- Reboot
and possibly some others…
But does not work in general for the use case of:
“After this task has successfully completed”
“Do this task right now”
I’m not sure if notify could be improved to handle thie use-case
without breaking existing user-cases. But it sounds ot me l ike
we need an “exec <task_name>” that I described above.
Has anyone else ran into this as well?
What are your thoughts?
Right now, I’m solving this problem by doing
the following in my roles:
- include: …/…/common/tasks/ldconfig.yml
Where ldconfig.yml looks like:
It sounds like you are doing it right to me.
You have an ordered list of dependent tasks. If one task fails, don't
continue because it'll likely bork you system,
unless you know for sure its okay, in which case set 'ignore_errors'.
For more fine grained control, you might want to add something like a
register: foo
for the first task and a
when: foo.changed
to the second task (or appropriate variations).
K
You should do this with a
register: task
then putting your exec in a second task with
when: task.changed
(1.2 syntax)
Serge
Correct.
Under 1.1, which does not have the benefit of cleaned up variables, it looks roughly like this:
when_boolean: ${task.changed}
Thank you both for your responses.
Whilst I understand I can “register a variable” and “conditionally perform a task”
I don’t find this particularly very intuitive. It makes far more sense to me (except
that notify isn’t designed this way) to “call a task” (i.e: notify) when one taks has
successfully completed. think of an event rather than a conditional execution.
This isn’t particular intuitive. But this is:
Except notify isn’t designed like this 
cheers
James
Understood. One of the the challenges of open source is that things intuitive to one person aren’t intuitive to everyone.
We will be sticking with “when: foo.changed” as that allows you to keep the task at exactly the point where it will run in the task list, which makes things clear, and also allows stuff like:
when: foo.changed and bar.changed and x > 3
etc
We’ve got thousands of people using things this way and they’ve been ok with it so far.
While I am open to adding new language constructs, we add them rather conservatively, as we aim to support things indefinitely.
I have ried this using register but I’m unable
to make this work. See this snippet:
-
name: Build/Install GDAL
action: command make install
chdir=/usr/local/src/gdal-$gdal_version
creates=/usr/local/bin/gdal-config
register: last_result
-
include: …/…/common/tasks/ldconfig.yml
when: last_result.changed
This cannot work because of the “creates” condition
applied to the build task. the condition “last_result.changed”
failed because it’s never defined.
I’m not sure how to solve this.
cheers
James
I often find, with the boolean conditional, I have to do things like
when: last_result is defined and last_result.changed
Or variations.
Hope this helps.
K
You used to be able to use "when_set: last_result", but the new documentation only shows example of "when".
“This cannot work because of the “creates” condition
applied to the build task. the condition “last_result.changed”
failed because it’s never defined.”
Ok, this is an easy one. I need to make the “skipped” data that returns from the command module also return “changed=False”.
I will make this happen.
Actually this is already done and works fine in latest git for me.
Did you test it on recent code?