Global variables file

1,716 views
Skip to first unread message

Ivaylo Bratoev

unread,
Sep 25, 2014, 4:41:12 PM9/25/14
to ansibl...@googlegroups.com
I need to define truly global variables. I know about using the *ALL* group_vars but the variable there are not truly global. For example if *groupname* is defined in for the *ALL* group in group_vars this doesn't work:

- host: {{ groupname }}
  ...

My questions are: Is this expected to work? If not, can we think of truly global variables or this is not a supported scenario?

In my opinion it is OK to make the variables from the all group be available globally.

Matt Martz

unread,
Sep 25, 2014, 5:55:16 PM9/25/14
to Ivaylo Bratoev, ansibl...@googlegroups.com
What you probably want to use is 'vars_files' in a play and load in a YAML file.  Those vars are scoped more globally, and not tied to individual hosts or groups.


--
You received this message because you are subscribed to the Google Groups "Ansible Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-deve...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Matt Martz
@sivel
sivel.net

Ivaylo Bratoev

unread,
Sep 26, 2014, 4:42:49 PM9/26/14
to ansibl...@googlegroups.com, ivaylo....@gmail.com
Yeah, that's how we do it in the moment. What I don't like is that *vars_files* has to be repeated on every play or include. A conventional way to include truly global variables would be great. What do you think about making from the *ALL* group truly global? I am no expert but it seems this would be completely backwards compatible.

Michael DeHaan

unread,
Oct 1, 2014, 8:37:05 AM10/1/14
to Ivaylo Bratoev, ansibl...@googlegroups.com
The group_vars/all file alongside inventory is loaded for everything, just at lower priority.

I use it frequently for global things.

Ansible in general likes it when you only have variables defined in one place - it's fine if you don't - but it's designed to be simple.  Thus as long as you don't need them to be super-high-priority, group_vars/all is a great place for that.


Ivaylo Bratoev

unread,
Oct 2, 2014, 8:27:07 AM10/2/14
to ansibl...@googlegroups.com, ivaylo....@gmail.com
michael,

I use the same group_vars/all approach but it is *not* truly global. Example (from my first post):

playbook.yml :

- host: {{ groupname }}
  tasks
:
   
- name: test
      raw
: ls

inventory/group_vars/all :
groupname: localhost

1. If I run *ansible-playbook -i inventory playbook.yml* - this fails with no hosts matched because {{ groupname }} is undefined on host level.
2. If I run *ansible-playbook -i inventory playbook.yml --extra-vars "groupname=localhost"* - this work as expected because groupname defined on command line is trully global.

Do you think that the first scenario should work as well? Can we consider this a bug or is this by design?

Michael DeHaan

unread,
Oct 2, 2014, 4:19:42 PM10/2/14
to Ivaylo Bratoev, ansibl...@googlegroups.com
This is not a thing, but if you were going to hardcode it, you could hardcode it like 

--extra-vars "@vars.yml"

Ansible will fail if the variable is undefined, so there'd be no worry of leaving if off.


Ivaylo Bratoev

unread,
Oct 3, 2014, 2:58:43 PM10/3/14
to ansibl...@googlegroups.com, ivaylo....@gmail.com
Yeap, that's another solution I am aware of but I think it would be cleaner to have global variables declared conventionally. The situation right now is - if you want truly global variables, you should pass them on the command line.

That's just my opinion. Definitely this is not a showstopper just a minor workaround ;)

Strahinja Kustudić

unread,
Oct 5, 2014, 3:40:17 PM10/5/14
to ansibl...@googlegroups.com, ivaylo....@gmail.com
I also needed global variables from time to time as well. Maybe we could add something like global_vars/ or something like that?

Or even better allow vars_file to be included on the playbook level, so it is automatically used in all plays of the playbook, that would remove the need for -e "@vars.yml".

Michael DeHaan

unread,
Oct 6, 2014, 8:26:05 AM10/6/14
to Strahinja Kustudić, ansibl...@googlegroups.com, Ivaylo Bratoev
Sorry, this isn't going to be a thing.

We don't want to introduce more levels of variable features at this time and would like to keep them well managed.

Strahinja Kustudić

unread,
Oct 6, 2014, 8:33:48 AM10/6/14
to Michael DeHaan, ansibl...@googlegroups.com, Ivaylo Bratoev

But what is a problem with vars_files being defined on top of a playbook? It should work the same as if we added the same vars_files to all plays, I don't see a downside to that and it should probably be even easy to implement it.

Ivaylo Bratoev

unread,
Oct 6, 2014, 9:18:56 AM10/6/14
to ansibl...@googlegroups.com, mic...@ansible.com, ivaylo....@gmail.com
Alternatively, we can make variables for the *all* group to be *truly* global and not introduce any new variables sources ;)

For me this would be a nice addition but it is not critical. I am OK with not doing anything for the moment.

Strahinja Kustudić

unread,
Oct 6, 2014, 10:17:42 AM10/6/14
to Ivaylo Bratoev, ansibl...@googlegroups.com, Michael DeHaan
Changing how group_vars/all works could possibly introduce a lot of problems to old playbooks and plays, but making it possible to set vars_files on playbook level won't introduce any, since it wasn't possible before.


Strahinja Kustudić
| Lead System Engineer | Nordeus

--
You received this message because you are subscribed to a topic in the Google Groups "Ansible Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-devel/gCyhboUlYic/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-deve...@googlegroups.com.

Michael DeHaan

unread,
Oct 6, 2014, 4:32:33 PM10/6/14
to Strahinja Kustudić, Ivaylo Bratoev, ansibl...@googlegroups.com
Indeed, we don't want to keep moving precedence controls around.

as such, we will not be making any changes.

Reply all
Reply to author
Forward
0 new messages