Also, isn't it weird the with the variable foo set to string "false" both "when: foo" and "when: not foo" evaluate to false?
On Wed, Aug 13, 2014 at 1:42 PM, Michael Peters <[email protected]> wrote: > Thanks, this works. > > I was under the impression that the 2 syntax variants (yaml vs > key-value) worked the same. Is this something that should be fixed or > just documented as a difference? > > On Wed, Aug 13, 2014 at 12:25 PM, Matt Martz <[email protected]> wrote: >> If you use the pure YAML complex args way of invoking a module, you can make >> it an actual boolean: >> >> - set_fact: >> foo: False >> >> But due to the fact that you cannot do that with jinja2 variable expansion >> and such, I'd recommend just sticking to using the |bool filter at >> evaluation time. It's more reliable and safer that way. >> >> >> On Wed, Aug 13, 2014 at 10:31 AM, Michael Peters <[email protected]> >> wrote: >>> >>> Is there a way to use set_fact to force it to use a real boolean >>> instead of the string? In the real playbook other tasks and includes >>> further down don't care where the var came from and I'd rather not >>> have to alter every boolean to run things through the bool filter just >>> in case the var came from set_fact. >>> >>> I tried >>> >>> - set_fact: foo={{ false }} >>> and >>> - set_fact: foo={{ false | bool }} >>> >>> But neither of those work. >>> >>> On Wed, Aug 13, 2014 at 11:19 AM, Matt Martz <[email protected]> wrote: >>> > What is happening is that you are effectively setting foo to the string >>> > "false" >>> > >>> > What you likely want to do is: >>> > >>> > when: not foo|bool >>> > >>> > >>> > On Wednesday, August 13, 2014, Michael Peters >>> > <[email protected]> >>> > wrote: >>> >> >>> >> Before I file a ticket, I just want to make sure I'm not doing >>> >> anything wrong. BTW, this is a simplified example to reproduce the >>> >> problem, not what I was actually trying to do. I have this simple >>> >> playbook test.yml: >>> >> >>> >> --- >>> >> - hosts: 127.0.0.1 >>> >> connection: local >>> >> tasks: >>> >> - set_fact: foo=false >>> >> >>> >> - command: ls / >>> >> when: not foo >>> >> >>> >> Executed like this: >>> >> >>> >> ansible-playbook -i '127.0.0.1,' test.yml >>> >> >>> >> >>> >> Which results in the following output: >>> >> PLAY [127.0.0.1] >>> >> ************************************************************** >>> >> >>> >> GATHERING FACTS >>> >> *************************************************************** >>> >> ok: [127.0.0.1] >>> >> >>> >> TASK: [set_fact foo=false] >>> >> **************************************************** >>> >> ok: [127.0.0.1] >>> >> >>> >> TASK: [command ls /] >>> >> ********************************************************** >>> >> skipping: [127.0.0.1] >>> >> >>> >> Notice the last task is skipped. So for some reason it's not following >>> >> the logic of the when clause like I'd expect. But the really weird >>> >> thing is that if I change the task to say "when: foo" (reverse the >>> >> logic) I get the same output: >>> >> >>> >> --- >>> >> - hosts: 127.0.0.1 >>> >> connection: local >>> >> tasks: >>> >> - set_fact: foo=false >>> >> >>> >> - command: ls / >>> >> when: foo >>> >> >>> >> Executed like this: ansible-playbook -i '127.0.0.1,' test.yml >>> >> >>> >> PLAY [127.0.0.1] >>> >> ************************************************************** >>> >> >>> >> GATHERING FACTS >>> >> *************************************************************** >>> >> ok: [127.0.0.1] >>> >> >>> >> TASK: [set_fact foo=false] >>> >> **************************************************** >>> >> ok: [127.0.0.1] >>> >> >>> >> TASK: [command ls /] >>> >> ********************************************************** >>> >> skipping: [127.0.0.1] >>> >> >>> >> Same output. So even if something with my logic was wrong (for >>> >> instance set_fact didn't like the literal "false") you would still >>> >> think that taking out the "not" would result in the task being >>> >> executed. >>> >> >>> >> ansible 1.8 (devel 9edf3a749a) last updated 2014/08/13 14:03:10 (GMT >>> >> +000) >>> >> >>> >> Am I doing something wrong? Or should I file a bug report? >>> >> >>> >> -- >>> >> 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/CAJQqANdAt%3D3PB30cEDMqknJHY%2BAr3VwpxePrgN4J-dvfeZUWGQ%40mail.gmail.com. >>> >> For more options, visit https://groups.google.com/d/optout. >>> > >>> > >>> > >>> > -- >>> > Matt Martz >>> > [email protected] >>> > http://sivel.net/ >>> > >>> > -- >>> > 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/CAD8N0v_XppVmJ_%3DzxCn7NrbbyAOjLueX%2BqJz%2Ba23nQq62vTJBA%40mail.gmail.com. >>> > 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/CAJQqANd92zR_QLV588wmVqF%2B7Ywitc2D1JJjbBtSd4cfGfBLzw%40mail.gmail.com. >>> >>> For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> -- >> Matt Martz >> [email protected] >> http://sivel.net/ >> >> -- >> 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/CAD8N0v8UM%3DiKL2%2B0N-voLv7a42gn5Ay5dEB9-%2B0SEaKgHiFouA%40mail.gmail.com. >> >> 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/CAJQqANcV4JdBJPAkws%2B4Q-TOwBCh9WwQWOZKcwgR9W%3DFC4Y7Cw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
