Yeah, that is why I'm trying to explain my needs as well as how I've currently modeled so people with more experience can suggest better ways to solve the problem.
I tried to use the the parameterized variables as inputs as well but that also leaks. For example if you do: # app1 - include: nginx port=8500 # app2 - include: nginx Now app2 is configured on port 8500, instead of complaining that the port var isn't defined or using the default 80. You can't have logic that is when: port is defined, because it *is* defined even though I feel it shouldn't be. On Tuesday, July 1, 2014 12:31:04 PM UTC-7, Michael DeHaan wrote: > > "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] > <javascript:>> 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] <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/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/eb20304e-0558-4ae5-8463-76ce3bdf1357%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
