I wanted to jump back into this conversation. It has been interesting. I did like Kesten's use of command line variables, but it looks like it is a better practice to have conditional inclusion of variables that are specific to a particular use of a role if I read this right.
We certainly have use cases like Kesten's where I want to reuse a role but change variables. For instance, using the Nova compute module in a role to provision, it is ideal to have flexible variables to define the users OpenStack environment and project details like image IDs, security groups and other user specific configurations. The ability to include variable files via the main in the "vars/" directory of a role seems it would be an improvement, and would be more consistent with the behavior of "tasks/", but perhaps there is a specific reason this was not implemented from the get-go. On Mon, Jan 20, 2014 at 4:01 PM, Michael DeHaan <[email protected]>wrote: > " It would be nice if include_vars at the top of the file would get > loaded even when starting at a task below that." > > If include vars is below a task they are definitely injected into the > namespace by the time a task below it is executed. > > If you mean you want to write include vars after a task apply to a task > before, this can't happen, because the path may be derived from a > registered variable or a call to a custom fact module, etc. > > > > > On Mon, Jan 20, 2014 at 6:33 PM, kesten broughton < > [email protected]> wrote: > >> >> >> On Sunday, January 19, 2014 2:29:17 PM UTC-6, Michael DeHaan wrote: >>> >>> I'd find that above a bit of an anti-pattern. >>> >>> If you want to include multiple files and have that role associated >>> versus play associated, the best way to do this is to use the >>> "include_vars" module inside a task file. >>> >>> There's an open RFE to include every file in "vars/" automatically with >>> "main" coming first, but I'm thinking we're likely to close that idea >>> entirely -- as conditional includes are useful things. >>> >>> >>> >> >>> I had most of the items using include_vars to begin with, but I make >>> heavy use of --start-at-task while developing scripts / debugging. >>> >> It would be nice if include_vars at the top of the file would get >> loaded even when starting at a task below that. >> It's hard to imagine a case where that would be bad. >> >> >> >> >> On Sun, Jan 19, 2014 at 11:00 AM, kesten broughton <[email protected] >>> > wrote: >>> >>>> Another approach that is working for me is to pass in a vars file that >>>> points to all the other vars files that you may need that change from run >>>> to run. >>>> >>>> ansible-playbook -i hosts site.yml -e "@cluster_config.yml" >>>> >>>> The use case is for creating clusters of hadoop based apps that have a >>>> high degree of configuration for various environments. >>>> I find ansible's variables architecture ideal for setting up a >>>> situation that is more or less the same from run to run. >>>> But when you have network variables that change from one datacenter to >>>> the next, or a cluster configuration that depends on staging/prod/dev >>>> I find In need a more robust and de-coupled way of passing in re-usable >>>> but swappable configs. >>>> Note that you could do this by putting all the vars into a >>>> group_vars/cluster_name.yml but then you have to get creative with groups >>>> or lose the re-usability of components that can be shared between groups. >>>> >>>> Here's how i do it. >>>> >>>> cluster_cards/deployment_name/cluster_config.yml in my ansible >>>> playbook directory contains >>>> network_config: "path to networking details for deployment" >>>> hadoop_config: "path to architecture of hadoop cluster" >>>> environment_config: "path to file with specific dev/prod config stuff" >>>> >>>> Then in site.yml (or a tasks file with include_vars: ) >>>> - hosts: hadoop_cluster >>>> vars_files: >>>> - ["{{network_config}}] >>>> - ["{{environment_config}}] >>>> - ["{{hadoop_config}}] >>>> >>>> deployment1/network_config_1.yml >>>> /environment_config.yml >>>> deployment2/network_config_2.yml >>>> >>>> / >>>> shared/small_hadoop_cluster.yml >>>> /medium_hadoop_cluster.yml >>>> >>>> I still use the ansible hierarchy of vars for less >>>> variable/configurable constants, but this has worked well for me >>>> >>>> kesten >>>> >>>> On Friday, January 17, 2014 11:14:06 AM UTC-6, AmiableAlbion wrote: >>>>> >>>>> I am struggling to break out variables in the "var" directory of roles >>>>> into individual files >>>>> >>>>> I have tried and continue to get tracebacks. I thought this would be >>>>> straight forward after seeing the documentation for include_vars, but >>>>> evidently I am missing something here. >>>>> >>>>> I was trying something like this with Ansible 1.4.4 >>>>> >>>>> *vars/main.yml* >>>>> *- include_vars: credentials.yml* >>>>> *- include_vars: imagenames.yml* >>>>> >>>>> *vars/imagenames.yml* >>>>> >>>>> *centos64: 52225cb3-441b-47b6-9cca-deb14d24d72f* >>>>> *rhel64: 364cd1c1-e958-4327-a0b4-3251da47869c* >>>>> >>>>> *> ansible-playbook vm.yml* >>>>> *Traceback (most recent call last): File >>>>> "/usr/bin/ansible-playbook", line 269, in <module> >>>>> sys.exit(main(sys.argv[1:])) File "/usr/bin/ansible-playbook", line 209, >>>>> in main pb.run() File >>>>> "/usr/lib/python2.6/site-packages/ansible/playbook/__init__.py", line 229, >>>>> in run play = Play(self, play_ds, play_basedir) File >>>>> "/usr/lib/python2.6/site-packages/ansible/playbook/play.py", line 83, in >>>>> __init__ ds = self._load_roles(self.roles, ds) File >>>>> "/usr/lib/python2.6/site-packages/ansible/playbook/play.py", line 327, in >>>>> _load_roles roles = self._build_role_dependencies(roles, [], self.vars) >>>>> File "/usr/lib/python2.6/site-packages/ansible/playbook/play.py", line >>>>> 192, in _build_role_dependencies role_vars = >>>>> utils.combine_vars(vars_data, role_vars) File >>>>> "/usr/lib/python2.6/site-packages/ansible/utils/__init__.py", line 1008, >>>>> in >>>>> combine_vars return dict(a.items() + b.items())AttributeError: 'list' >>>>> object has no attribute 'items'* >>>>> >>>>> Perhaps I am abusing syntax here though ... >>>>> >>>>> Thanks >>>>> Albion >>>>> >>>> -- >>>> 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]. >>>> >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>> >>> >>> >>> -- >>> Michael DeHaan <[email protected]> >>> >>> 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 [email protected]. >> >> To post to this group, send email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > > > -- > Michael DeHaan <[email protected]> > > CTO, AnsibleWorks, Inc. > http://www.ansibleworks.com/ > > -- > 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/LgiQ6CRHRCY/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]. > For more options, visit https://groups.google.com/groups/opt_out. > -- Albion Baucom gRED IT Support Pharma Informatics -- 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]. For more options, visit https://groups.google.com/groups/opt_out.
