Hi guys,
Not sure if this has been resolved, but I'm getting really strange behavior
with my playbooks in version 1.4. This has nothing to do with --extra-vars,
but a boolean variable defined in the "vars" section. Or am I defining it
somewhat incorrectly?
Here is an example:
- hosts: 127.0.0.1
vars:
myvar: "{{ 'foo' == 'bar' }}"
tasks:
- name: print var value
command: /bin/echo {{ myvar }}
- name: this should run
command: /bin/echo whatever
when: not myvar
- name: this should not run
command: /bin/echo whatever
when: myvar
This prints "False" for the first task and skips both the other tasks.
However, if I change the "when" statements to myvar|bool, it works as
expected.
So it seems myvar contains the string representation of the boolean
expression returned from the statement.
Is there a way to have the variable of type boolean, or do I always have to
explicitly pipe it to the Jinja bool filter?
On Tuesday, April 16, 2013 1:27:12 AM UTC+2, Michael DeHaan wrote:
>
> It's just fed to the variable system to be avialable in templating/other
> usage, well-post YAML parsing...
>
>
> On Mon, Apr 15, 2013 at 7:19 PM, Kahlil Hodgson
> <kahlil....@dealmax.com.au<javascript:>
> > wrote:
>
>>
>> On Tue, Apr 16, 2013 at 8:59 AM, Michael DeHaan
>> <mic...@ansibleworks.com<javascript:>
>> > wrote:
>>
>>> It has nothing to do with foo=yes not being YAML.
>>
>>
>> Obviously not had enough coffee to express myself clearly.
>>
>> What I meant was 'foo=yes' on the command line does not _look_ like YAML,
>> so we should not _expect_ it to behave like YAML.
>>
>> I'm assuming 'foo: yes' in an ansible YAML file gets the boolean cast via
>> some python library for importing YAML and not via ansible's variable
>> system?
>>
>> --
>> Kahlil (Kal) Hodgson GPG: C9A02289
>> Head of Technology (m) +61 (0) 4 2573 0382
>> DealMax Pty Ltd (w) +61 (0) 3 9008 5281
>>
>> Suite 1415
>> 401 Docklands Drive
>> Docklands VIC 3008 Australia
>>
>> "All parts should go together without forcing. You must remember that
>> the parts you are reassembling were disassembled by you. Therefore,
>> if you can't get them together again, there must be a reason. By all
>> means, do not use a hammer." -- IBM maintenance manual, 1925
>>
>> --
>> 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 <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>
>
> --
> Michael DeHaan <mic...@ansibleworks.com <javascript:>>
> CTO, AnsibleWorks, Inc.
> http://www.ansibleworks.com/
>
>
--
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-project+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
