Using `notify` with an `include` statement silently fails

725 views
Skip to first unread message

Tadej Janež

unread,
Sep 24, 2014, 10:23:44 AM9/24/14
to ansible...@googlegroups.com
Hi!

I've recently been bitten by this unintuitive behaviour. For example, in
a task like this:

- include: foo.yml
notify:
- test handler

the 'test handler' is (silently) not being run.

Even adding 'changed_when: true', i.e. changing the above to:

- include: foo.yml
changed_when: true
notify:
- test handler

doesn't help.

The whole minimal reproducing example is here:
https://github.com/tjanez/ansible-using_notify_with_include_bug

My questions are the following:
1) Is this the expected/intended behaviour?
2) If yes, should we warn the user that using notify with an include
statement will not work?

Thanks and best regards,
Tadej

Michael DeHaan

unread,
Sep 24, 2014, 10:28:42 AM9/24/14
to ansible...@googlegroups.com
It's working-as-designed behavior with regard to not being able to do what you have, but not perfect - it should report on the error condition.

There's currently no "notify" logic like you have attached to an include, and what is happening is the "include" "object" doesn't really have validation associated with it to the level that it should.

I'm not sure it should yell at you, as IMHO this should define variables:

- include: foo.yml x=2

is a thing

as such

- include: foo.yml
  x: 2

should be a thing also.

As such, notify would just be another word.

Now if variables aren't taking in that case, that's a bug.

This is tricky, I know - but basically my advice in the past is, if you see syntax in the docs, it's syntax.   But if you make something up, you might just be passing data to something :)

I hope this is understandable.  It's somewhat the nature of it being a data format.

Now, if you want to "tag" every task in an include with a handler, that *may* be the first time I've seen that.  It seems a little curious.  Are there specific tasks you might want to affix a handler to instead?




--
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 ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/1411568107.3990.11.camel%40tlinux64.
For more options, visit https://groups.google.com/d/optout.

tadej...@gmail.com

unread,
Sep 24, 2014, 11:09:03 AM9/24/14
to ansible...@googlegroups.com
Hi!

First, thanks for a quick answer!


On Wednesday, September 24, 2014 4:28:42 PM UTC+2, Michael DeHaan wrote:
It's working-as-designed behavior with regard to not being able to do what you have, but not perfect - it should report on the error condition.

Ok, I see. Thanks for clearing it up!


There's currently no "notify" logic like you have attached to an include, and what is happening is the "include" "object" doesn't really have validation associated with it to the level that it should.

I'm not sure it should yell at you, as IMHO this should define variables:

- include: foo.yml x=2

is a thing

as such

- include: foo.yml
  x: 2

should be a thing also.

Yes, agreed. I use often use such variable passing (:) with include statements, since it is more readable when variables have longer values.
 

As such, notify would just be another word.

Aha, I see now. It's hard to say, what should be the proper behaviour. Would it maybe make sense to warn the user that he is passing a variable named 'notify' to the include statement rather that notifying the desired handler?
 

Now if variables aren't taking in that case, that's a bug.

No, that's working perfectly.
 

This is tricky, I know - but basically my advice in the past is, if you see syntax in the docs, it's syntax.   But if you make something up, you might just be passing data to something :)

I hope this is understandable.  It's somewhat the nature of it being a data format.

Not intuitive at first, but obvious now :).
 

Now, if you want to "tag" every task in an include with a handler, that *may* be the first time I've seen that.  It seems a little curious.  Are there specific tasks you might want to affix a handler to instead?

What happened in my concrete case was that the last task in a series of tasks deploying some web server application was to include some common YAML file and that I have a habit of adding notify statement to the last task in a series. So, nothing special :). 

Thanks and regards,
Tadej
Reply all
Reply to author
Forward
0 new messages