Yep, the vars plugin will (currently) be evaluated once per host.



On Mon, Mar 24, 2014 at 11:41 AM, Serge van Ginderachter <
[email protected]> wrote:

> Another option might also be to write your own vars_plugin.
> Though working with an inventory script, as Michael put it, is the better
> way to do it, and will also be a lot more performant.
>
>
> On 24 March 2014 15:37, Kesten Broughton <[email protected]>wrote:
>
>> In a previous 
>> thread<https://groups.google.com/forum/#!topic/ansible-project/LgiQ6CRHRCY>,
>> it was discussed how one could apply deployment specific vars to a play.
>>  My solution at the time was to pass in a master config "pointer" file via
>> the commandline with the -e "@filename" idiom containing file names that
>> could be loaded by vars_files or include_vars.
>>
>> ansible-playbook -i hosts site.yml -e "@cluster_config.yml"
>>
>> Then in site.yml (or a tasks file with include_vars: )
>>  - hosts: hadoop_cluster
>>    vars_files:
>>      - ["{{network_config}}]
>>      - ["{{environment_config}}]
>>      - ["{{hadoop_config}}]
>>
>>
>> Michael suggested this was an anti pattern and I did find a maintenance
>> problem because of all those vars_files lines sprinkled about the playbook.
>>
>> My preferred method is now to modify the hosts file to add additional
>> deployment specific groups to the top of the hosts file and have the vars
>> loaded automatically via group_vars.
>>
>> Currently, the group_vars loader does what I would call "Immediate folder
>> match".  If a top level folder in group_vars matches any of the groups, all
>> descended files and folders ending in .yml will be loaded.
>>
>> This prevents hierarchical groupings of deployments.  I would like to
>> organize my deployments like this
>>
>> [kbroughton@mb-kbroughton:lynx-ansible/dev-ansible + (develop)] tree
>> ../21ct-ansible/group_vars/
>> ../21ct-ansible/group_vars/
>> ├── all
>> └── datacenter
>>     ├── datacenter.yml
>>     ├── production
>>      |       ├── production.yml  # vars common to all prod systems
>>       │      └── client1_prod
>>      │               ├── client1_app.yml
>>      │      └── client2_prod
>>      │               ├── client2_app.yml
>>      └── staging
>>         ├── staging.yml
>>         ├── client1_stag
>>         │   ├── client1_stag.yml
>>         │   ├── client1_app.yml
>>         └── client2_stag
>>
>> Each step of the descent, files in a matching folder are loaded but only
>> matching subfolders will be descended into.
>>
>> I'm writing this to open discussion again on how to best accomplish
>> deployment-specific vars.  At the moment, my solution is to modify the
>> signature of the _load_vars and related methods in
>> ansible 
>> <https://github.com/ansible/ansible>/lib<https://github.com/ansible/ansible/tree/devel/lib>
>> /ansible <https://github.com/ansible/ansible/tree/devel/lib/ansible>/
>> inventory<https://github.com/ansible/ansible/tree/devel/lib/ansible/inventory>
>> /*vars_plugins*group_vars.py
>>
>> to pass in groups information.
>> Then I add the checking that only descends into a directory if it is a in
>> groups[host].
>>
>> The default behavior could remain as it is with a new variable in
>> .ansible.cfg
>> group_vars_load_strategy: { one of HIERARCHICAL_FOLDER_MATCH,
>> IMMEDIATE_FOLDER_MATCH - the current behavior
>> }
>>
>> Would a pull request along these lines be considered, or is there an
>> alternate preferred method that achieves the deployment-specific vars
>> management we need?
>>
>> kesten
>>
>>
>>
>> --
>>
>> Kesten Broughton
>> 512 701 4209
>>
>> --
>> 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/CAO2fFsVtAEsnDC_JsE5Z5qsyrfYDOKHLhYwT_6NZWsiUbyvF%2BA%40mail.gmail.com<https://groups.google.com/d/msgid/ansible-project/CAO2fFsVtAEsnDC_JsE5Z5qsyrfYDOKHLhYwT_6NZWsiUbyvF%2BA%40mail.gmail.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/CAEhzMJA80L0Q3Bou0hkRV_Zzmq2-%3De6mCUu98hDn4EN0-P_ePA%40mail.gmail.com<https://groups.google.com/d/msgid/ansible-project/CAEhzMJA80L0Q3Bou0hkRV_Zzmq2-%3De6mCUu98hDn4EN0-P_ePA%40mail.gmail.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/CAEVJ8QOuUvtNHeBiHKib-BR4cQCgEMHcqr6%3DJARPSh56Wt2Jgg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to