List of Ansible default variables

[9dev...@gmail.com]

Does Ansible provide predefined variables to use in scripts? I am looking for variables like:
- current host
- current group
- current user
- current task
- current role
etc.

I have not found these variables among these from "gathering facts".

[Matt Martz]

Here are the ones that I can recall and easily find in the source:

vars

always_run

changed_when

delegate_to

failed_when

ignore_errors

inventory_dir

playbook_dir

register

The vars variable, is a dictionary, that contains all of the above vars as key/value pairs.

inventory_file

inventory_hostname_short

inventory_hostname

ansible_ssh_user

hostvars

group_names

groups

defaults

environment

Also, anything from --extra_vars, host_vars/, group_vars/, facts.d/, register, etc...

Some of this is mentioned on <http://www.ansibleworks.com/docs/playbooks_variables.html> , pay some special attention to <http://www.ansibleworks.com/docs/playbooks_variables.html#id22>

But to address some of your specifics:

- current host

inventory_hostname, and inventory_hostname_short

- current group

There isn't really a var that says, this is the current group being acted on, but per host has a 'groups' var containing all groups that host is a member of

- current user

Perhaps ansible_ssh_user ?

- current task

This is not exposed

- current role

This is not exposed

-- 
Matt Martz
ma...@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 ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Michael DeHaan]

Matt's answer above is slightly incorrect.

Things like "always_run" and such are keywords, not variables that are usable in scripts.

http://ansibleworks.com/docs/playbooks_variables.html#magic-variables-and-how-to-access-information-about-other-hosts

(The statement about their being other variables is not accurate and will be removed next time docs are pushed, I have that queued up right now)

You should also look into facts:

http://ansibleworks.com/docs/playbooks_variables.html#id17

I think if you need a variable that defines your current role, it's probably the sign of a modeling problem -- with a few possible exceptions.  The role shouldn't have to know what it's name is to operate correctly.

--

Michael DeHaan <mic...@ansibleworks.com>
CTO, AnsibleWorks, Inc.
http://www.ansibleworks.com/

[John Anderson]

I disagree that needing the current role is a modeling problem.  I've actually just ran into this problem, but I'm willing to hear better solutions.

We have 40 different web applications and a set of load balancers, so we need to have settings for the webservers like what port their nginx

should listen on but the load balancer *also* needs to know these settings so that it can configure the pools for each node.

How do you store settings that are globally accessible but attached to a specific role if you don't know what the current role is?

For example our settings file looks like this:

services:

  anonweb:

    repo: anonweb

    version: upgrade_latest_packages

    port: 8500

    nginx_port: 6005

    paths:

      - /

  addressbookweb:

    repo: AddressBookWeb

    version: develop

    port: 8765

    nginx_port: 6014

    paths:

      - /addressbook

So we configure a pool for all the nodes in the addressbookweb group to listen on nginx port 6014, and then when a request to

/addressbook comes into the loadbalancer it routes to that specific pool.  But when we setup the addressbook nodes we also need

to configure nginx properly to listen on that port.

So we do this by doing:

     services[current_role].nginx_port

But do access current_role we had to set a variable for *every* role.

[Michael DeHaan]

"I disagree that needing the current role is a modeling problem. "

"We have 40 different web applications and a set of load balancers, so we need to have settings for the webservers like what port their nginx

should listen on but the load balancer *also* needs to know these settings so that it can configure the pools for each node."

This is a bit of a logical fallacy -- lots of folks using Ansible have a lot more than 40 different web applications, for one.   Secondly, having variables like nginx_port would allow access to this via hostvars.

All of this could be done with group_vars just fine without needing to know the path of the current role as a variable.

I don't believe a role needs to know it's current name, because of all the vars/defaults/tasks/templates machinery allows finding those sub-paths without needing those things.

This may just be more of a case of rethinking how you are modelling things in Ansible.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/37134b03-c4e6-49df-91da-07e691d23310%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Timothy Appnel]

What you are describing sounds a lot like what I have at my day job -- hundreds of instances of dozens of Java applications each with their own properties like unique ports, file paths and whatnot.

We addressed the things you are talking about by treating each app as a host regardless of physical server and from there used host and groups vars, not roles for what you are trying to do. Essentially roles start with tasks and sometimes specialized modules. The variables and defaults are there to support those tasks. Recently I created a module that reads the properties file all of these application use for their configuration and imports them as facts so later roles and playbooks can remain in sync with little to no effort.

We did toy with something like your approach of wrapping application specific meta data as roles, but found that was messy and hard to manage. (Roles get checked in and treated like code, inventory not so much.)

So based on my experience I think your struggles are a modeling problem like Michael suggested.

<tim/>

[Michael DeHaan]

Good points Tim!

I should probably add that when I wrote ansible, I was thinking all about inventory and groups as a method of categorization.

The roles are all about applying behavior to specific combinations of groups - and roles are just abstractions around task and variable boilerplate.

Larger organizations are going to be more and more inclined to dynamic inventory and sources of truth - but the point at which someone needs this can vary.

--
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.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/519faf83-1f5c-4058-a189-0689ffe46905%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Marc Abramowitz]

On Tuesday, July 1, 2014 10:19:16 AM UTC-7, John Anderson wrote:

So we configure a pool for all the nodes in the addressbookweb group to listen on nginx port 6014, and then when a request to

/addressbook comes into the loadbalancer it routes to that specific pool.  But when we setup the addressbook nodes we also need

to configure nginx properly to listen on that port.

So we do this by doing:

     services[current_role].nginx_port

But do access current_role we had to set a variable for *every* role.

How about this?

# roles/anonweb/tasks/main.yml

{ include: ../../../roles/pythonapp/tasks/main.yml, app_role: anonweb } 

# roles/addressbookweb/tasks/main.yml

{ include: ../../../roles/pythonapp/tasks/main.yml, app_role: addressbookweb }

# ../../../roles/pythonapp/tasks/main.yml

# do stuff nginx config stuff with {{ app_role }}

Ansible variables seem to have a global scope, because if I set one within the role it seems to be visible to all roles (which surprised me as I was expecting roles to be more self-contained since they're supposed to be reusable, shared on Galaxy, etc.). All roles are referencing the same named variable are sharing the same global variable. But the parameterized roles and parameterized includes are more akin to parameter passing and so the state is not shared.

[Michael DeHaan]

"Ansible variables seem to have a global scope, because if I set one within the role it seems to be visible to all roles"

No exactly true for roles.

Ansible variables set in one role are available in roles further down so you can have roles that describe an environment, but they do have scope.  In fact, you are guaranteed access to that particular value, without it being clobbered.

We've been through this a few times today on this list, in fact :)

--

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.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/0cc40dad-47d7-4c98-b1f0-2ba1de053e3f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Marc Abramowitz]

On Tuesday, July 1, 2014 6:43:32 PM UTC-7, Michael DeHaan wrote:

"Ansible variables seem to have a global scope, because if I set one within the role it seems to be visible to all roles"

No exactly true for roles.

Ansible variables set in one role are available in roles further down so you can have roles that describe an environment, but they do have scope.  In fact, you are guaranteed access to that particular value, without it being clobbered.

When you say "further down", are you referring to:

1. further down in a hierarchy (i.e.: a parent/child relationship where role A depends on role B so that role B is "further down" than role A in a hierarchy) 

2. further down in a sequential flow (i.e.: role A is applied and then role B so role B is "further down" in the playbook)

?

Talking with a colleague, I was assuming #1 and he was assuming #2.

I created a git repo that illustrates some behavior that surprised me. Most likely this is because I'm misunderstanding the paradigms at play; there's a small chance that it's a bug, but I figure the misunderstanding is more likely.

https://github.com/msabramo/ansible-roles-example

I would love to see an explanation of why this works the way it does so that I can have a deeper understanding of Ansible.

Thanks!

Marc

[Michael DeHaan]

I mean Roles utilized after other roles.   

I'm not going to read your git repo as we've been through this alot.

"I would love to see an explanation of why this works the way it does"

It's so you can have environmental role data like so:

- hosts: concord

  roles:

     - eastcoast_datacenter_config

     - puppies

- hosts: lexington

  roles:

    - eastcoast_datacenter_config

    - apache

    - random_app

And define variables in roles and have those variables, like the name of an NTP server, available further down.

--

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.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/d913befd-afde-4c1c-86a6-ea41523eef39%40googlegroups.com.

[Marc Abramowitz]

On Wednesday, July 2, 2014 2:38:48 PM UTC-7, Michael DeHaan wrote:

I mean Roles utilized after other roles.

OK, thanks for clarifying. That's good to know, since I want to understand clearly how things work before we get deep into this and start advocating for company-wide usage.

You might consider adding a note to the documentation about this (probably the "Variables" page). I looked around quite a bit and couldn't find anything that quite covered this "inter-role" behavior of variables. The basic gist being "variables set in one role are available to roles that execute sequentially afterwards".

I think we now understand and we've worked around our issue with a parameterized include, which we found to work by trial and error on our own.

That said, you may or may not be interested to know that in the git repo that I mentioned, I actually saw behavior that looks like a role was getting a value for a variable set in a LATER role. Not a big deal to us as we're using parameterized includes now, but I mention it just in case it's interesting or surprising.

[Michael DeHaan]

" I actually saw behavior that looks like a role was getting a value for a variable set in a LATER role"

I am occasionally incorrect.

Vars do get compiled down first, tasks run in order, as variables do run in order, but I'd expect that.

My apologies on not remembering correctly - I do think that's still fine due to the built-in protections around variable clobbering in roles (won't happen, etc).

--

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.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/df308498-2df8-49f1-84b6-45e66b1ff357%40googlegroups.com.

[Marc Abramowitz]

On Wednesday, July 2, 2014 3:49:28 PM UTC-7, Michael DeHaan wrote:

" I actually saw behavior that looks like a role was getting a value for a variable set in a LATER role"

I am occasionally incorrect.

Vars do get compiled down first, tasks run in order, as variables do run in order, but I'd expect that.

My apologies on not remembering correctly - I do think that's still fine due to the built-in protections around variable clobbering in roles (won't happen, etc).

Cool. Mistakes happen. The important thing is that you explained why it works the way it does, so we understand what to expect.

[James Morgan]

Sorry to bring this up again. Was there an answer for - current group?

I appreciate that I can find the groups that are set for a host but I need to know what the current group that is being acted on.

The group is defined in the playbook but I need to loop over the hosts for that group in a template and don't want all possible groups that the host is associated with

Many thanks

[Brian Coca]

current_host = inventory_hostname
current_group = no singular, we always flatten to host, you can check
the current host's groups in "group_names" list of the current host
current_user = lookup('env', 'USER') ?
current_task = nothing represents the current task .. since you are in
the current task ..., not sure what you want here.
current_role = role_path|basename


--
Brian Coca

[James Morgan]

Ok thanks, 

I think I will need to pass it through from the playbook, the issue is that on a flat deployment where every group has the same host, when I use group_names I get all possible groups, not the one currently being handled.

This meant that I ended up with a duplicate list of about 12 hosts. Is it possible to append to a list in jinja. If so I could loop over groups_names, then over the hosts in that group and build up a list of hosts then uniq the list

    {% for group in group_names %}

      {% for host in groups[group] %}

      ....

    <Location /admin>

      SetHandler otas-handler

      OTASHost 172.31.5.20 19202

      OTASHost 172.31.5.20 19202

      OTASHost 172.31.5.20 19202

      OTASHost 172.31.5.20 19202

      .....

Thanks for the consise list of the others, very useful.

[Brian Coca]

You seem to want the play_hosts variable (current active hosts in current play).

> --
> 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.
> To post to this group, send email to ansible...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/ansible-project/9aaf2756-36e6-43f1-bb5a-a8b6d6a1c076%40googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.

--
Brian Coca

[James Morgan]

Yep that does indeed sound like what I need. Will give it a shot

Many thanks

[Kale Franz]

Brian,

This is incredibly useful info and could be helpful to add to the official documentation.

Similar to the play_hosts variable, is there something like a "play_roles" variable that is an ordered list of roles for the current play?  I'd like to be able to trigger certain behavior (restarts and such) based on the presence or absence of particular roles in that list.