Hi Jan :) FWIW, we're just adding
- include: debian.yml when: ansible_distribution == 'Debian' or ansible_distribution == 'Ubuntu' - include: rhel.yml when: ansible_distribution == 'CentOS' or ansible_distribution == 'Red Hat Enterprise Linux' To the top of each role. Debian/Ubuntu specific stuff (because config files are in different locations as well as package names being different) goes in the debian.yml file and CentOS/RHEL stuff goes in rhel.yml Anything that is common to both (tagging for monitoring etc.) is in "main.yml" after the above include statements. I realise its not exactly what you're after but it might help? Cheers, Matt On Wednesday, 14 January 2015 20:05:34 UTC, Tom Bamford wrote: > > Hi Jan > > In terms of unified package management, I believe this is a direction that > the Ansible project decided not to go in. I think the cleanest way from a > playbook perspective would be to write your own module. But think about how > much this might involve, noting that apt, yum, pacman et al don't have > interchangeable functionality - yes there are some commonalities but are > really very different. That's not including other package managers > (thinking of npm, pip, rubygems etc). Also, package naming and what you do > with a package after installing it varies greatly depending on distro, and > by association, package manager. > > For the above, citing: > https://groups.google.com/d/msg/ansible-project/x2_9PzAJXNE/ZwcBv02oAhkJ > https://groups.google.com/d/msg/ansible-project/RxoxVVFdLhI/fNUYnH_sm-cJ > https://github.com/ansible/ansible/issues/4261 > > I like to keep OS dependant tasks either in separate task files, or > separate roles depending on the complexity. I don't believe in this case > that some duplication is a bad thing. > > Hope this helps. > > Tom > > > > On 14 January 2015 at 13:37, <[email protected] <javascript:>> wrote: > >> On Tue, 13 Jan 2015, Tom Bamford wrote: >> >> > If you want greater control of when your common tasks get executed, I >> would >> > be more inclined to use rules and have verbose playbooks with the >> execution >> > order explicitly specified. >> > >> > Perhaps if you could give a better idea of what your common tasks are >> and >> > the context in which you want to run them? >> >> The common tasks involve configuring containers (it doesn't matter what >> kind of container; that's liable to change) then installing software >> elements into it and registering services. >> >> >> However, to pick a simpler, concrete example, let's say I've a playbook >> that needs to install a package, foo. >> >> I want to use this playbook against both apt and yum-based systems; and >> possibly against systems that use other packaging mechanisms in the >> future. >> >> [[[ >> - apt: name=foo >> when: system == 'apt' >> >> - yum: name=foo >> when: system == 'yum' >> ]]] >> >> >> Do I really need to repeat this logic everywhere I might want to install a >> package? What I'm after is the ability to write: >> >> - package: name=foo >> >> and centralise the code that picks a concrete implementation. >> >> Is there already a way to express this simple kind of abstraction in >> ansible? I know I can do something like >> >> - include: ../../common/tasks/install-package.yml name=foo >> >> but writing this is klunky and error-prone; I'm just wondering if there >> are neater ways to achieve this - so that playbooks can separate the >> "what" and the "how". >> >> Cheers, >> jan >> >> >> >> -- >> [email protected] <javascript:> http://ioctl.org/jan/ Short, dark, ugly: >> pick any three >> I shave with Occam's Razor. >> > > > -- 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/561a12cd-a93d-4376-81eb-d8d5aff19456%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
