Hi guys,
It’s the way it’s going to work. Let’s let it go 
–Michael
Update on this older thread since we recently ran into some gotchas with using hashes as a way to isolate variable namespace for roles.
For example if every role has a variable named “code_base_dir” you might name it “_code_base_dir” or put “code_base_dir” in a hash named <role_name>.
The latter option is tidier but it caused some problems so we are back to using underscores.
For example this didn’t seem to work for role “foo” and is probably not supposed to work:
foo:
code_base_dir = /path/to/foo
some_file = “{{ foo.code_base_dir }}/somefile”
Where this does work and something we do often in our vars/main.yml files:
foo_code_base_dir = /path/to/foo
foo_some_file = “{{ foo_code_base_dir }}/somefile”
Another problem was that if you need to override {{ foo.some_file }} you will need to turn on the hash merging setting which is fine but isn’t by default turned on.
In general we also find it easier to troubleshoot since grep’ing through the playbooks for “foo_some_file” is easier than grepping for a hash.
So for now I think our convention will need to be that every variable defined in a role will need to be prefixed with the role name.
-John
foo:
code_base_dir = /path/to/foo
some_file = “{{ foo.code_base_dir }}/somefile”
This doesn’t work because it’s not valid YAML syntax. You need colons, not equal signs.
Well that too (bad paste), but this was not working either:
foo:
code_base_dir: /path/to/foo
some_file: “{{ foo.code_base_dir }}/somefile”
If you think it should work I can take a look again.
Templating probably only happens at one point in time here, rather than multiple times recursively, in order to resolve that.
Old style variables DO work that way, but it was something I observed to seem unneccessary in Jinja2 in at least top level variables, since Jinja2 is all about what variables/symbols you have in that top level hash.
So I bet if you put basedir a level up it probably might work, worth a shot:
foo_basedir: X
foo:
code_base_dir: “{{ foo_basedir }}/xxxxx”
Yeah, putting the variable outside the hash works fine.
Does this qualify as a bug or as-designed or is it generally bad for us to be referencing variables in variable files like this to begin with?
It’s not a bug, more so something you would like to work that does not work.
Old style variables will allow referencing, but in general, I think it’s a sign things should be modelled simpler.
It’s not a bug, more so something you would like to work that does not work.
Old style variables will allow referencing, but in general, I think it’s a sign things should be modelled simpler when you are trying to do something like this.
If there’s a “Zen of Ansible” here, it’s “don’t try to overcomplicate things”
Yeah the ultimate goal is to definitely make things less complicated by coming up with scheme to organize variables namespace in a sane way.
I think the simplest approach will be for us to have a general rule that for roles you should prefix variable names with the role name.
Old style variables will allow referencing,
The new style does as long as they aren’t in hashes:
https://github.com/edx/configuration/blob/master/playbooks/roles/xqueue/vars/main.yml
I definitely want to know if this qualifies as something that you think is too complicated.
-John
Looks pretty reasonable to me!
Coming late to this discussion, also i’m clumsy with this forum interface, so i might be double posting, but
i just discovered that roles don’t implement true namespaces: http://pastebin.com/9W378CiQ, and found this
thread by searching.
The thread seems to express similar concern, with a proposal to resolve it with a “role prefix conveintion” for variables,
with (over simplified) arguments against being a) simplicity is key, b) we don’t want too many conventions, and c) there’s
years of existing implementation that would be hard to change.
I propose an alternative: when you enter a role, you enter a true namespace by default.
a) in the ‘postgres’ role, $libdir = /var/lib/pgsql/data, while in the ‘snmp’ role, $libdir = /usr/share/snmp.
(it’s the global variables which should be prefixed…). you don’t get much simpler than that.
to me, the most important thing roles can provide is encapsulation.
b) it follows established programming convention, so no need for new conventions.
c) roles, to me, are still new enough that we should get them right
the obvious downside: it’s hard, and would require banging on some core ansible code.
ansible has so much right, and is important enough to me, that i’d be willing to spend some time on this… so i guess
my question at this point is, does anyone share this vision? if coded to appropriate standards, does it have a chance
of being accepted by the community?
–bowe
I think that’s a reasonable thing to do, load stuff into the parameterized role namespace and also load them into the global namespace.
I suspect this is probably about a 5-7 line patch.
It would ensure the local variable is always used locally, but could still be referenced by other roles.
–Michael
Hi!
I know it’s an old topic, but would like to dig it out for newcomers.
I’ve noted, that role variables in Ansible 2.0 are namespaced!
Have a look at my test: https://gist.github.com/kzarzycki/0a82497ed72756b722c56a62ab9f0ab5
That’s the behavior I’m a fan of
Cheers,
Krzysztof
W dniu niedziela, 4 sierpnia 2013 01:37:58 UTC+2 użytkownik Michael DeHaan napisał: