There is also a bigger issue in here. Variables are lazy evaluated
(https://github.com/ansible/ansible/issues/10374).
So if for example you include a role and use a variable evaluation in its
args, you have absolutely no way if ensuring what is going to be the value
when that arg is used inside the role.
roles/some_role/tasks/main.yml:
---
- include_role:
name: some_other_role
args:
my_variable: "{{ some_variable }}"
roles/some_role/vars/main.yml:
some_variable: SOME_VARIABLE
roles/some_other_role/tasks/main.yml:
- debug: var=my_variable
roles/some_other_role/vars/main.yml:
some_variable: SOME_VARIABLE_WITH_VALUE_FROM_OUTSIDE
The result:
PLAY [all]
***********************************************************************************************************************************************************************
TASK [Gathering Facts]
***********************************************************************************************************************************************************
ok: [127.0.0.1]
TASK [some_role : include_role]
**************************************************************************************************************************************************
TASK [some_other_role : debug]
***************************************************************************************************************************************************
ok: [127.0.0.1] => {
"changed": false,
"my_variable": "SOME_VARIABLE_WITH_VALUE_FROM_OUTSIDE"
}
PLAY RECAP
***********************************************************************************************************************************************************************
127.0.0.1 : ok=2 changed=0 unreachable=0 failed=0
So my_variable is lazy evaluated inside the role, and given that there is
another variable defined with the same name, the value gets evaluated
inside.
Conclusion, If you use a third party role (ansible galaxy?) and pass a
variable as an argument, and that role happen to use a variable which
clashes with one used in the args, the value is going to be whatever value
it has inside the role.
That makes modules completely unusable, code cannot be reused in Ansible?.
El jueves, 13 de julio de 2017, 16:15:36 (UTC+2), Jose Luis Fernández Pérez
escribió:
>
> But still, I think that a proper mechanism for role scoping should be
> implemented, if you try to reuse code odds are that you end up having
> several roles with several variables declared inside each job. Things like
> 'path' or 'port' are expected to be declared inside those roles, either by
> vars statements while including or inside the role.
>
> Imagine the following scenario
>
> vars (vars/main.yml)
> porrt:3000
>
>
> metafile (meta/main.yml):
> dependencies:
> - { role:nginx_server }
>
> task (tasks/main.yml):
> -include_role:
> unicorn_server
> args:
> listen: {{ port }}
>
>
> In the dependency you don't specify a role so an internal port variable is
> used (lets say port 80)
>
> The second one has parameter that you set to port, but given that you
> misspelled it in the vars file you end up having an 80 here. This should be
> an 'undefined variable' because you should not bother with name clashing.
>
> El jueves, 13 de julio de 2017, 15:54:06 (UTC+2), Brian Coca escribió:
>>
>> Actually, include_role is currently bugged in that it does NOT expose
>> the vars. So I would not rely on that behaviour.
>>
>> ----------
>> Brian Coca
>>
>
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/078166dc-76f3-4463-9165-d4c53db49b36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
