The problem with doing <rolename>_var is that you can no longer have
generic configuration. Here is what I currently have:
# roles/nginx/tasks/main.yml
- name: setup the nginx conf
sudo: true
action: template src=nginx.jinja2 dest=/etc/nginx/sites-enabled/{{ role
}}.conf
notify: restart nginx
when: deploy_env is not defined
tags:
- nginx
# roles/nginx/templates/nginx.jinja2
{% set application = role %}
upstream {{ application }}_pool {
server 127.0.0.1:{{ services[role].port }};
}
server {
listen {{ services[role].nginx_port }} default;
server_name_in_redirect off;
port_in_redirect off;
access_log /var/log/sm/{{ application }}.access.log sm;
location / {
proxy_set_header host $host;
real_ip_header X-True-Origin;
proxy_pass http://{{ application }}_pool;
}
}
# roles/app1/tasks/main.yml
- include: ../../../roles/nginx/tasks/main.yml
# roles/app2/tasks/main.yml
- include: ../../../roles/nginx/tasks/main.yml
and so lets say I want to deploy app1 and app2 each to 3 of their own nodes
and 1 shared node that they are both on. I could make this happen by
creates roles/<app>/vars/main.yml that look like this:
# roles/app1/vars/main.yml
nginx_port: 6005
port: 8500
# roles/app2/vars/main.yml
nginx_port: 6014
port: 8765
but now when I want to configure my load balancers I have no access to
those vars to be able to get what nginx_port I need to proxy to for each
role. So exposing the variables globally for the load balancer works:
# group_vars/all
services:
app1:
port: 8500
nginx_port: 6005
app2:
port: 8765
nginx_port: 6014
but now the app roles don't have access to it because they don't know what
role they are. So then if you mix both approaches, keep that previous
group_vars/all and change the app vars to look like this:
# roles/app1/vars/main.yml
role: app1
# roles/app2/vars/main.yml
role: app2
Now everything will just work, unless you create "app3" and forget to set
the role: app3 in it, because you wont be alerted that you forgot to set
the var, it'll just happily take whatever the previous app that was
configured
said it was and use it.
That is where I am at today, I had this all working and then added app3 and
the load balancer was sending all traffic to app3 and there wasn't a clear
reason *why* the app3 loadbalancer pool thought it should route to app2.
So this is what I'm trying to solve.
On Tuesday, July 1, 2014 11:39:16 AM UTC-7, Michael DeHaan wrote:
>
> "I understand having the ability to set a variable at a more global scope
> is important but I think by default it should not."
>
> Opinion noted, though we're not going to be changing things.
>
> Sounds like your roles should use variables like rolename_varname if you
> want to build things this way.
>
>
>
>
> On Tue, Jul 1, 2014 at 12:52 PM, John Anderson <[email protected]
> <javascript:>> wrote:
>
>> Maybe if I discuss what I'm trying to do there will be a better solution
>> so that variable scope doesn't matter.
>>
>> I have an SOA architecture (40 python web services) and want each one
>> defined as their own role because they can be deployed on their own nodes
>> or on shared nodes.
>>
>> So my tree structure looks like this:
>>
>> http://paste.ofcode.org/aWr2A77wxXezkanhWHm5nC
>>
>> For every role I have a line in my group_vars/all file that defines
>> metadata about the role like what nginx port they use, if they use
>> requirements.txt, etc. This looks like this:
>>
>> $ cat group_vars/all.yml
>> ---
>> 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
>>
>> <snip>
>>
>> and so if I want to deploy the usersvc role to 3 nodes in the staging
>> environment I do the following:
>>
>> ansible-playbook -i nova.py -u monkey deploy.yml --extra-vars
>> "group=mc3-usersvc role=usersvc"
>>
>> but then after I get them deployed I need to run my loadbalancer role to
>> grab the hosts from my dynamic inventory
>> file and each of the nodes to the load balancer configuration, which
>> means it needs to grab the nginx port and everything
>> that it will be proxying to on each node.
>>
>> All this works as expected because I've defined 1 specific role I want to
>> deploy so the var is globally scoped and can be used
>> every where but if I want to update the load balancer for *all* roles I
>> have no way of getting what the "current" role is, so all my
>> current configuration fails.
>>
>> Which brings us to where we are now, I tried to define role/<role>/vars/
>> file with one setting role=<role> that way all the
>> configuration would still run. But I forgot to to set this in 3 roles
>> and they ended up getting configuration for the role that ran before
>> them because the variable scope was contained to where I defined it (like
>> it would be in standard python without the global keyword).
>>
>> This caused mayhem because now my load balancer is routing to the wrong
>> nodes and it isn't very clear *why*. I want it to fail and
>> alert me that I forgot to define a variable.
>> ----------------
>> I understand having the ability to set a variable at a more global scope
>> is important but I think by default it should not.
>>
>> So with my minor example, the pythonapp is generic configuration and one
>> of the checks it does is "when: use_req_text is defined" and each role can
>> decide if it should use a requirements.txt to install.
>>
>> My problem now is that only half of my 40 projects use requirements.txt
>> but since Ansible is leaking the information it tries to use
>> requirements.txt for all of them.
>>
>> Is my only option to have to explicitly set this var in every role and
>> accept the fact that forgetting to do so will have bad consequences?
>>
>> On Tuesday, July 1, 2014 7:52:59 AM UTC-7, Michael DeHaan wrote:
>>
>>> It doesn't leak information in any way that is a problem, but rather the
>>> variable is still in scope.
>>>
>>> Variables from roles are available in other roles, but always guaranteed
>>> to be used WITHIN that role.
>>>
>>> Thus if you set in one role X, "a: 42"
>>>
>>> and another role Y, "a: 44"
>>>
>>> ansible is so written that role X always gets 42 and tasks in role Y
>>> always get 44.
>>>
>>> They won't clobber one another.
>>>
>>> Having one role being able to define variables for another is however
>>> important, for instance, a role might define presensce in a particular
>>> datacenter and define a server address used in other roles.
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Jul 1, 2014 at 6:17 AM, John Anderson <[email protected]> wrote:
>>>
>>>> I have the following structure:
>>>>
>>>> roles/pythonapp/
>>>> roles/billingsvc/
>>>> roles/usersvc/
>>>>
>>>>
>>>> pythonapp is a generic set of instructions like cloning and installing
>>>> a python package, billingsvc and usersvc both include it in their tasks.
>>>>
>>>> I have a variable that I set in billingsvc/vars/main.yml and I don't
>>>> want usersvc to see this var but as soon as billingsvc finishes it runs
>>>> usersvc and the var is there.
>>>>
>>>> Is there anyway to prevent this leaking of information? I've defined
>>>> the var in the role vars section specifically to keep it isolated from
>>>> everything else.
>>>>
>>>> --
>>>> 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/d96b6d38-e618-4c8a-b06a-
>>>> 5843a3cf36df%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/ansible-project/d96b6d38-e618-4c8a-b06a-5843a3cf36df%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>> 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] <javascript:>.
>> To post to this group, send email to [email protected]
>> <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/ansible-project/7133b4d5-74e7-48ef-b78a-1dca39e607fa%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/ansible-project/7133b4d5-74e7-48ef-b78a-1dca39e607fa%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
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/f9c58aeb-5778-401a-b2ed-6e1a01d1f226%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
