Hi, Thanks for the response. We have lots of playbooks & lots of inventories. I plan on creating more groups to better define the behaviour instead of setting at the inventory level.
Re the role issue. I think the problem was around 1.6 group_vars/all vs other group_vars/ precedence changed. We used to have all defaults in group_vars/all.yml and override in the other groups. To try and fix this and move away from having a dumping ground of variables we moved them into relevant roles. The variables may be needed in other playbooks or roles. I.e applications conf.d directory. So to get the variable we would include_vars. We wouldn't want to run the role just get the variable. Sorry if I haven't been clear. Its quite difficult to convey how we do things. We automate everything with ansible. Our system has 50-100 of our own applications built on a stack of similar number of open source tools and apps, data stores etc. So there is a fair amount of coupling. On the whole Ansible works very well for us. Its just edge cases that get fiddly with the precedence. On Thursday, 22 October 2015 14:41:39 UTC+1, Josh Smift wrote: > > JM> I was just trying to work out in what situation would you want to have > JM> the inventory level group/host vars at a lower precedence than the > JM> playbook level group/host vars. It doesn't really fit with the way we > JM> are doing things. > > My guess is that the expectation is that you'd typically have one > inventory, which is very consistent, but lots of playbooks, some of which > might want to do things differently. Having a playbook that's generally > consistent, but can be overridden by inventory, seems to me like a less > common use case, but of course if it's the one you've got then it's the > one you care about. :^) > > You mentioned that you > > struggle with default values that don't aren't defined in a role. I > appreciate that that is the preferred approach but this would mean that > we would have to include the role default everywhere we use it. > > I'm not sure what you mean by "have to include the role default". If you > use the role, you get the role default, so could you maybe get what you > want here by just moving the contents of the playbook into a role? > > -Josh ([email protected] <javascript:>) > > > > This email is intended for the person(s) to whom it is addressed and may > contain information that is PRIVILEGED or CONFIDENTIAL. Any unauthorized > use, distribution, copying, or disclosure by any person other than the > addressee(s) is strictly prohibited. If you have received this email in > error, please notify the sender immediately by return email and delete the > message and any attachments from your system. > -- 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/68d1629e-e37b-44be-9ec7-d14fd7d08b02%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
