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]> 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] 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/CAAnNz0Nh0FDL9Z5SbuWCpUPH7AFtRbG6LLg%2B5syxxMZLoiuWJg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
