Don't worry about it being a "leak". Know that that this variable will be guaranteed to be as passed in within the scope of that roll.
Namespace your variables if you feel the need, etc. On Tue, Jul 1, 2014 at 3:45 PM, John Anderson <[email protected]> wrote: > 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]> 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-e >>>>>>> 618-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/eb20304e-0558-4ae5-8463-76ce3bdf1357%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/eb20304e-0558-4ae5-8463-76ce3bdf1357%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%2BnsWgye61sSXyEiG3wCDxBo%2B68J0hBCeHn5E%2BnMio6N50-xAA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
