"The problem with doing <rolename>_var is that you can no longer have generic configuration. Here is what I currently have:"
I don't believe this is a problem, and think some of your complexity comes with how you are modelling things. If you define a role, a role can take parameterized variables as inputs, for instance, which will override any defaults the role sets. On Tue, Jul 1, 2014 at 3:27 PM, John Anderson <[email protected]> wrote: > 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]> 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]. >>> 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/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 > <https://groups.google.com/d/msgid/ansible-project/f9c58aeb-5778-401a-b2ed-6e1a01d1f226%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/CA%2BnsWgxbGbQSYhD60nc0S%2Bv5v%2BJbKrkOYuRT5dUEbqfDogSbnQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
