Sorry, i missed the "distributing plugins" section at the bottom http://docs.ansible.com/developing_plugins.html#distributing-plugins
However, i'm not clear if dropping my group_vars into ansible/plugins/vars_plugins/group_vars.py will run before, after or instead of lib/ansible/inventory/vars_plugins/group_vars.py? Is there a way to specify ordering / precedence of files in a plugin directory? Maybe just point me to the plugin loader code? k On Tue, Apr 1, 2014 at 9:50 AM, Kesten Broughton < [email protected]> wrote: > Thanks serge and michael. > > I'm not opposed to writing my own plugin, though I'm basically happy with > group_vars.py. My change is just the 5 lines here. > > # directory > if stat.S_ISDIR(pathstat.st_mode): > > # support organizing variables across multiple files in a directory > * if GROUP_VARS_STRATEGY == 'HIERARCHICAL_FOLDER_MATCH':* > > * if os.path.basename(path) in groups:* > * return True, _load_vars_from_folder(groups, path, > results)* > * else:* > * return True, results* > * else:* > return True, _load_vars_from_folder(groups, path, results) # > the original group_vars.py line > > So what is the porper way to get ansible to use my_group_vars.py as the > plugin rather than group_vars.py? I would like to keep pulling in future > changes to group_vars.py and just run off a local branch with my patch > applied. Should i just locally over-write group_vars.py or is there a > proper plugin switch? I will have to distribute my plugin across multiple > users. > > kesten > > On Monday, March 24, 2014 10:43:19 AM UTC-5, Michael DeHaan wrote: >> >> 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 a topic in the > Google Groups "Ansible Project" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/ansible-project/oIQzp6nCs7k/unsubscribe. > To unsubscribe from this group and all its topics, 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/8c38baf0-f7c0-47de-ac42-3257ab91890a%40googlegroups.com<https://groups.google.com/d/msgid/ansible-project/8c38baf0-f7c0-47de-ac42-3257ab91890a%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAO2fFsU%3DUO%3DO08T3pCM8RAvGK4%3DQsCxCnD6kBvL0Tcu1ph9Xxg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
