Ultimately at some point everyone would like some different way something is handled, we work by observing the patterns and implementing those things as they come.
My advice to you is to not think too much about variables and defaults, and look at how to simplify your infrastructure. There are basic mechanisms there, but if you have to worry about what overrides what, it can get confusing. It's usually better to just define something in one place. Role defaults are great for defining parameters that might not be passed for roles, but to default things in inventory, put something in group_vars/all and more specific groups will override it, etc. We assuredly want to limit the number of ways we expand how variables work, since complexity is not something we're after... this does mean looking at ansible differently, which can sometimes present challenges when folks are coming from, e.g., Chef and want to look at it like an outright programming language. To me, includes inside variable files don't make sense, because that whole structure exists to define variables, not include tasks. I'm a little less against the idea of "- include_defaults" but it would lead, IMHO, to bad role design. I think it would be better to step back and see what you are trying to model, to understand you use case about the apps you are deploying, and then to suggest the way most people are modelling it in terms of current best practices. On Wed, Aug 27, 2014 at 5:14 PM, Daniele Varrazzo < [email protected]> wrote: > > On Wednesday, August 27, 2014 9:15:22 PM UTC+1, Michael DeHaan wrote: >> >> Correct, you could symlink a main.yml but not stick another file in there >> with a different name. >> >> The reason for this is some folks use those for conditional includes (of >> vars/) directories, so auto-loading them would cause more confusion than >> it's worth. >> > > I see, so I think the idea of symlinking the 'main.yml's is ruled out too > (as the web role may need to declare some defaults itself). > > If it is not currently possible to achieve what I need, I can imagine > several ways ansible could be extended to allow that: > > - allowing some form of include command inside defaults/main.yml (which > may work for vars too). I see the problem in the file being just a yaml > dict, not a more generic structure. I guess conditional stuff couldn't be > executed either as you don't know the vars yet to test them... > > - adding an include_defaults, like include_vars but with the variables > precedence at lower level. This may also allow for conditionals or > ignore_errors; > > - allowing multiple files in vars/defaults, disabled by default for the > people who add files there for conditional inclusions as you explained. > E.g. there could be a "role_vars_glob" defaulting to "main.yml" that > somebody could set to "*.yml" if required. Then symlinks could be used. > > I think the first solution is the one that would make more sense but I > guess it's harder to implement. So probably the second idea is more > manageable (if include_vars proved to be a good idea, include_defaults > should work too). The third feels more an hack to allow another hack, but > it may be the easiest to implement. > > Would any of these approaches be a welcome improvement? Or there is > something just fundamentally wrong in my deployment approach (it could be, > it is the first time I use ansible for such a complex task - but that's > what it's for, isn't it?). Is there a way to use just vars/main.yml and > include_vars in the tasks but then be able to override them from the > inventory? Sometimes I think group vars should be more powerful than role > vars (that's why I'm trying to use defaults instead). > > I'll be happy to try and hack on ansible if any of these approaches make > sense; or to change my deployment configuration if there is better way to > organize my rules. > > Thank you for any comment. > > -- Daniele > > -- > 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/3fedcaa6-ad1c-41b8-8444-13b37ce80e6f%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/3fedcaa6-ad1c-41b8-8444-13b37ce80e6f%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%2BnsWgy%3DdZYHJrU3qivN4_urVv%3DXdJfiODuaE-LmGQGoJML_sw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
