"I disagree that needing the current role is a modeling problem. "

"We have 40 different web applications and a set of load balancers, so we
need to have settings for the webservers like what port their nginx
should listen on but the load balancer *also* needs to know these settings
so that it can configure the pools for each node."

This is a bit of a logical fallacy -- lots of folks using Ansible have a
lot more than 40 different web applications, for one.   Secondly, having
variables like nginx_port would allow access to this via hostvars.

All of this could be done with group_vars just fine without needing to know
the path of the current role as a variable.

I don't believe a role needs to know it's current name, because of all the
vars/defaults/tasks/templates machinery allows finding those sub-paths
without needing those things.

This may just be more of a case of rethinking how you are modelling things
in Ansible.



On Tue, Jul 1, 2014 at 1:19 PM, John Anderson <son...@gmail.com> wrote:

> I disagree that needing the current role is a modeling problem.  I've
> actually just ran into this problem, but I'm willing to hear better
> solutions.
>
> We have 40 different web applications and a set of load balancers, so we
> need to have settings for the webservers like what port their nginx
> should listen on but the load balancer *also* needs to know these settings
> so that it can configure the pools for each node.
>
> How do you store settings that are globally accessible but attached to a
> specific role if you don't know what the current role is?
>
> For example our settings file looks like this:
>
> 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
>
> So we configure a pool for all the nodes in the addressbookweb group to
> listen on nginx port 6014, and then when a request to
> /addressbook comes into the loadbalancer it routes to that specific pool.
>  But when we setup the addressbook nodes we also need
> to configure nginx properly to listen on that port.
>
> So we do this by doing:
>
>      services[current_role].nginx_port
>
> But do access current_role we had to set a variable for *every* role.
>
>
> On Monday, December 30, 2013 8:34:55 AM UTC-8, Michael DeHaan wrote:
>
>> Matt's answer above is slightly incorrect.
>>
>> Things like "always_run" and such are keywords, not variables that are
>> usable in scripts.
>>
>> http://ansibleworks.com/docs/playbooks_variables.html#
>> magic-variables-and-how-to-access-information-about-other-hosts
>>
>> (The statement about their being other variables is not accurate and will
>> be removed next time docs are pushed, I have that queued up right now)
>>
>> You should also look into facts:
>>
>> http://ansibleworks.com/docs/playbooks_variables.html#id17
>>
>> I think if you need a variable that defines your current role, it's
>> probably the sign of a modeling problem -- with a few possible exceptions.
>>  The role shouldn't have to know what it's name is to operate correctly.
>>
>>
>>
>>
>> On Mon, Dec 30, 2013 at 10:35 AM, Matt Martz <ma...@sivel.net> wrote:
>>
>>> Here are the ones that I can recall and easily find in the source:
>>>
>>> vars
>>> always_run
>>> changed_when
>>> delegate_to
>>> failed_when
>>> ignore_errors
>>> inventory_dir
>>> playbook_dir
>>> register
>>>
>>> The vars variable, is a dictionary, that contains all of the above vars
>>> as key/value pairs.
>>>
>>> inventory_file
>>> inventory_hostname_short
>>> inventory_hostname
>>> ansible_ssh_user
>>> hostvars
>>> group_names
>>> groups
>>> defaults
>>> environment
>>>
>>> Also, anything from --extra_vars, host_vars/, group_vars/, facts.d/,
>>> register, etc...
>>>
>>> Some of this is mentioned on <http://www.ansibleworks.com/
>>> docs/playbooks_variables.html> , pay some special attention to <
>>> http://www.ansibleworks.com/docs/playbooks_variables.html#id22>
>>>
>>> But to address some of your specifics:
>>>
>>> - current host
>>>
>>> inventory_hostname, and inventory_hostname_short
>>>
>>> - current group
>>>
>>> There isn't really a var that says, this is the current group being
>>> acted on, but per host has a 'groups' var containing all groups that host
>>> is a member of
>>>
>>> - current user
>>>
>>> Perhaps ansible_ssh_user ?
>>>
>>> - current task
>>>
>>> This is not exposed
>>>
>>> - current role
>>>
>>> This is not exposed
>>>
>>>  --
>>> Matt Martz
>>> ma...@sivel.net
>>>
>>> On December 30, 2013 at 8:54:53 AM, 9dev...@gmail.com (9dev...@gmail.com)
>>> wrote:
>>>
>>>  Does Ansible provide predefined variables to use in scripts? I am
>>> looking for variables like:
>>> - current host
>>> - current group
>>> - current user
>>> - current task
>>> - current role
>>> etc.
>>>
>>> I have not found these variables among these from "gathering facts".
>>> --
>>> 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 ansible-proje...@googlegroups.com.
>>> To post to this group, send email to ansible...@googlegroups.com.
>>>
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>  --
>>> 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 ansible-proje...@googlegroups.com.
>>> To post to this group, send email to ansible...@googlegroups.com.
>>>
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>
>>
>> --
>> Michael DeHaan <mic...@ansibleworks.com>
>>
>> CTO, AnsibleWorks, Inc.
>> http://www.ansibleworks.com/
>>
>>   --
> 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 ansible-project+unsubscr...@googlegroups.com.
> To post to this group, send email to ansible-project@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/37134b03-c4e6-49df-91da-07e691d23310%40googlegroups.com
> <https://groups.google.com/d/msgid/ansible-project/37134b03-c4e6-49df-91da-07e691d23310%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 ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgyitmiteoV5DuF58HtZ7_NraMA9dh752c9xkoT1dBJCCA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to