I’ve been working on describing all of the options & useful combinations possible in a playbook by writing one LONG super-commented playbook. This is about 60% done, but I’d love feedback and comments. Is this useful to you? Anything else you’d like to see?
https://gist.github.com/2897937
Thanks!!
Fred,
Is this useful to you?
this is useful for beginners like myself; thank you.
Anything else you'd like to see?
The example states that vars cannot be expanded inside the vars
section ($config); how about an example with YAML &something and
*something ? [I forget their official term for that...]
-JP
I’ve heard them called “anchors” – I’m not sure they are usable for substrings.
Making vars used later on in the vars list is something a small patch could achieve, we’d just have to repeatedly template each line with the results of the vars storage.
Not ideal, but doable.
–Michael
> The example states that vars cannot be expanded inside the vars
> section ($config); how about an example with YAML &something and
> *something ? [I forget their official term for that...]I've heard them called "anchors" -- I'm not sure they are usable for
substrings.
Indeed; I hadn't thought of that.
Making vars used later on in the vars list is something a small patch
could achieve, we'd just have to repeatedly template each line with
the results of the vars storage.Not ideal, but doable.
Useful!
-JP
Fred Alger wrote:
I've been working on describing all of the options & useful combinations possible in a
playbook by writing one LONG super-commented playbook. This is about 60% done, but I'd love
feedback and comments. Is this useful to you? Anything else you'd like to see?
I think this is a great idea, it definitely would have helped me get started
a lot faster.
A few comments though. Line 36 starts a play, not a playbook. You can have
multiple plays in a playbook, that is the strength of the playbook in my
opinion. The play can also be named, by default the name is whatever the
hosts field is set to.
I think line 112 saying that variables in variables won't be fixed is
incorrect, my understanding is that it is something that will be fixed.
I'm confused by what the comment says for line 120. The variable will
always be set to the same thing, but if used in only_if can be a Python
expression to determine whether a task should be run on this particular
host.
Lines 270-273, 286-287, 305-306 are missing an indentation.
Yes, this is excellent, and will be very helpful for a person new to ansible (like me).
I’d love to see this completed. If you were willing to do do even more, and give additional examples demonstrating nice, scalable approaches to common ansible configuration and deployment use cases, I’d love that as well. Go pedantry! 
Thanks.
John
I enjoyed the read! Nice work, Fred!
Very nice.
I've also compiled some playbooks here:
https://github.com/cocoy/ansible-playbooks
I hope it will help others too.
I don’t know what that means either
Sorry, my brain failed when I wrote that section. There are three things going on:
Right now, variables set IN the vars section can’t be used in the vars section. There’s an enhancement issue filed for 0.5 about this.
Variables defined BEFORE the vars section CAN be used in vars. For example --extra-vars=“…” and host group variables.
My understanding of conditionals in playbooks is weak. I’m going to experiment and brush up that section.
Fred,
What I do not understand is
Line 108: Variables do not expand inside the ‘vars’ section.
and then
Line 120: is_color_blue: “‘$color’ == ‘blue’”
That can be a bit confusing, but I think I can clear that up for you. The fine point here is that conditionals are expanded later and evaluated as python code.
So let’s when the vars section is evaluated, let’s say color=“red”. Then, is_color_blue is set, literally, to “‘$color’ == ‘blue’” (a string containing single quotes and a dollar sign).
If you’re new to Python, note that Python does not distinguish between single and double quotes (you just have to terminate with what you started).
Later, when the only_if is evaluated, a few things happen:
Hope that helps.
- Right now, variables set IN the vars section can’t be used in the vars section. There’s an enhancement issue filed for 0.5 about this.
This is now possible, FWIW…
Fred,
…Later, when the only_if is evaluated, a few things happen:
- The string “‘$color’ == ‘blue’” is expanded to “‘red’ == ‘blue’”.
- Python eval() is called: eval(“‘red’ == ‘blue’”)
- Since that returns False, the task is skipped.
I might have some of the deep timing details wrong, but that is the logic that’s happening: only_if’s receive strings that are expanded very late in the run and evaluated by Python.Hope that helps.
Very clear, thanks. I’ve worded things better in my example.
> 1. Right now, variables set IN the vars section can't be used in the
> vars section. There's an enhancement issue filed for 0.5 about this.This is now possible, FWIW…
I can't get this to work with the devel branch checked out just a few
minutes ago:
playbook
Jan-Piet Mens wrote:
> 1. Right now, variables set IN the vars section can't be used in the
> vars section. There's an enhancement issue filed for 0.5 about this.This is now possible, FWIW…
I can't get this to work with the devel branch checked out just a few
minutes ago:playbook
--------
---
- hosts: all
vars:
domain: example.org
server: www.${domain}
user: root
[...]
run
---
$ ansible-playbook jp.yamltarget-node
-----------$ egrep '(domain|server)' /etc/ansible/setup
"domain": "example.org",
"server": "www.${domain}"Did I misunderstand something?
Use it in the playbook. E.g.
tasks:
- name: test variables
action: shell echo $server >> /tmp/foo
/etc/ansible/setup gets the data as-is.
> playbook
> --------
> ---
> - hosts: all
> vars:
> domain: example.org
> server: www.${domain}
[...]
> $ egrep '(domain|server)' /etc/ansible/setup
> "domain": "example.org",
> "server": "www.${domain}"Use it in the playbook. E.g.
tasks:
- name: test variables
action: shell echo $server >> /tmp/foo
I'll try that (on the road at the moment), but:
/etc/ansible/setup gets the data as-is.
That's not very intuitive, is it? Furthermore, that means that the
variable $server (i.e. {{ server }}) can't be used in a template, I
assume?
-JP
/etc/ansible/setup gets the data as-is.
That’s not very intuitive, is it? Furthermore, that means that the
variable $server (i.e. {{ server }}) can’t be used in a template, I
assume?
/etc/ansible/setup is not really for public consumption, it’s an artifact of how the system works.
That variable can totally be used in a template. Templates are actually computed server side in 0.4 and beyond.
/etc/ansible/setup is not really for public consumption, it's an
artifact of how the system works.
Understood. Nevertheless, /etc/ansible/setup is useful: fetch it from
servers to have a parseable inventory.
That variable can totally be used in a template. Templates are
actually computed server side in 0.4 and beyond.
Then I'm really doing something wrong -- I don't get the variable in the
computed template, but where's my error? (Using commit
1b5d5feef37b5c821ffa32b2f079b727f6ead959)
-JP
template (temp.j2):
Fred, thanks for the awesome example. I have found a bug, in the example for what a vars_file should look like, you have :
Example YAML for a file to be included by vars_files:
# ---
# - monitored_by: phobos.mars.nasa.gov
# - fish_sticks: "good with custard"
# # (END OF DOCUMENT)
This doesn’t work, it needs to be changed to remove the initial ‘-’ from each variable, like so:
Example YAML for a file to be included by vars_files:
# ---
# monitored_by: phobos.mars.nasa.gov
# fish_sticks: "good with custard"
# # (END OF DOCUMENT)
I’m not sure how to send pull requests on gists.
Time for this useful example to get into a repo, I think. It’s outgrown gist.
I’m not sure how to send pull requests on gists.