"Is this something that should be fixed or just documented as a difference?"
Nope. It's fine, because the system has no hint to decide you asked for anything other than a string. On Wed, Aug 13, 2014 at 1:43 PM, Michael Peters <[email protected]> wrote: > 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. > -- 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/CA%2BnsWgzUFwwO-kQu3Fp7%3D6wrU%3DK%2Bw_qaAqhs0iDVhNnJZwAt1A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
