Hi,
Its been a while since I have posted, which is really a compliment to
all the awesome modules. We have signifcan number of our projects
covered by ansible.
Has anyone seen an issue gathering facts and getting Authentication failed?
Yes, I know. And that’s exactly what I want to utilize but which doesn’t seem to be working.
Let’s call this:
ansible-playbook foo.yml -e “myhosts=host17”
And the foo.yml would look like this:
hosts: {{myhosts}}:&dbserver
tasks: [some tasks]
hosts: {{myhosts}}:&webserver
tasks: [some other tasks]
Which would execute [some tasks] if host17 is member of dbserver and it would execute [some other tasks] if host17 is member of webserver. But that doesn’t work. It looks like when we use
hosts: {{myhosts}}
then the variable {{myhosts}} gets resolved but when using
To be honest, I’m often struggling with the right syntax with regard to variables. Is there an overview available that explains the correct synatx in all different context?
There’s really not such a thing as different contexts in 1.2 – playbooks and templates use {{ foo }} for variable interpolation equally, which is one of the very nice things about 1.2.
This is just a YAML syntax thing where you need to quote the line value.
There are a couple of special cases where YAML will try to ‘interpret’ the data strings used by ansible and require a work-around. I was thinking of adding a “Gotcha’s” section at the end of the YAML documentation to cover these. If this is desired, I’ll see if I can get a pull request together today.
It should definitely discuss the two following things:
foo: {{ splat }}
Should be
foo: “{{ splat }}”
And also
foo: bar msg=glorp:gluzz
Should be
foo: bar msg=“glorp:gluzz”
If a line contains a colon or starts with a “{”, quote the whole line.
I have long thought about making Ansible detect this on the fly and make it work via magic, so the question does not arise, but in doing so, we make the file not be YAML anymore, which is something I believe we shouldn’t do as true “infrastructure as data” is important to me.
Thankfully, it’s just those two gotchas that I know of.
Won’t work in a playbook, even though the argument does work on ‘ansible -m lineinfile’ command line,because of the ‘NOPASSWD: ALL’ You have to use the special YAML ‘>’ quoting trick to get around it:
As an aside, I agree that its probably not a good idea to make ansible do any magic preprocessing here. Introducing exceptions can make it harder to track down syntax errors if you don’t know all the rules that are in play (i.e. is it an YAML error, or an Ansible key-value error or a Jinja2 error). That’s one reason why I don’t like new magic continuation lines: playbooks that use them are technically not valid YAML and the existing YAML ‘>’ quoting mechanism does the same thing explicitly with just a single character added. Then again, its mostly harmless and I’m just being pedantic
K
Sorry Michael, don’t want to upset you, just looking for clarity.
The include + with_items must have been removed in the last 24 hours as I just found it there yesterday. But if it’s unsupported I will of course try and find a different approach. Any suggestions on how else I could achieve nested loops in playbooks then?
Your statement about colons isn’t quite clear, I’m afraid. Do you mean I should quote like “with_items: $group[‘webserver’]”? But why is it working in the other case with exactly the same line including a colon?
Just had a peak at the the new Gotchas section on the site. The workaround suggested might be a bit confusing for anyone who does not understand how YAML quoting works – which I think is the real gotcha.
Try running the following playbook:
hosts: localhost
connection: local
tasks:
debug: msg=“foo: bar”
A newbie might think the ': ’ has been quoted when it hasn’t. Even more confusing if they are using the command, shell or lineinfile modules and are trying to get their head around how/if their ‘quotes’ propagate. The first non-space character after the ': ’ sequence largely determines how the rest of the line/block is interpreted.
Yuck. I’ve been thinking about this for a solid 10 minutes and can’t come up with a sufficiently simple way of explaining YAML string values.
