Ansible currently has different modules (yum, apt) for software-package
management, meaning playbooks need to be customized depending on the
target platform. (Customization will be platform-specific usually in
some way, but I'm discussing software packages only at the moment.)
Has anybody here got experience with Smart [1] ? I don't (yet), but
judging by their advertising [1] it seems like an "ideal" system to use
together with Ansible.
Opinions? Alternatives?
-JP
Interesting question.
I’ve heard of it many years ago. Hasn’t really got any adoption that I’m aware of, and I’m not up to speed on what’s good or bad about it.
I am not sure if you are asking because you want one way to do it, or because you also want to use smart.
So I’ll answer both questions.
(1)
I am open to ansible having modules for other packaging types than yum and apt (within reason), though smart is used in such a small number of places it is probably not one I would want to include in core. I would like to see everyone just using yum or apt as appropriate and feel doing otherwise leads people astray. I think the core modules should ‘generally work’ and be in wide enough use that we quickly spot problems with them when they break. Smart wouldn’t be that. Basically I think the guideline is if I can visualize maybe 20% of the userbase using a module, that module is a good fit for core. I’m trying to avoid a bit of module bitrot that eventually plagued Func for accepting too many modules.
Not having looked at smart enough to judge it – Smart will definitely NOT replace the yum or apt module, nor will ansible require ever require smart. Minimal dependencies and using “what’s there” is a core goal for Ansible. smart isn’t something in core Fedora/CentOS installs by default, nor Debian/Ubuntu, so that makes it not an appropriate choice to consolidate yum and apt support around … unless the distributions did that in the future, around any particular package manager. In which case, we would add it, alongside the other two.
(2)
I don’t view the different yum and apt modules as a bad thing.
Ansible is different from things like Puppet in that it does NOT attempt to give you a wrapper around your package manager, and the way apt and yum works ARE different. In practice, your packages (and their names) are going to be different anyway and you need to know which systems are running which OS, so this is not something we’re looking to hide from the user, and those packages are going to need different config files. The idea of a cross platform recipe has never really held true for the Puppet Module site, I’m sure that’s also true of the Chef module site, and I think it’s best that we don’t pretend that these operating systems can be managed in a 100% cross-distribution compatible way. Apache is a prime example of being completely different between CentOS and Debian, and many modules are at least different in terms of paths and init scripts. So while you could abstract out the package installation if you dealt with the name differences, you ALSO have to push down different templates, etc, and at that point, I think it’s easier to recognize that these should just be different playbooks.
I also like that the apt and yum modules are separate codebases, and not one package module. This keeps the modules simple and we can support features easily that are only in one or the other. For instance, update-cache in the apt module is one example of something that is not needed in yum.
–Michael
I am open to ansible having modules for other packaging types than yum
and apt (within reason)
I'm not opposed to differenciating between apt and yum; it's more a case
of intending to use Ansible with SLES which has neither: they use
Zypper. (And I'm probably not enough of a Pythonista to implement a
`zypper' module. 
And then there are the BSD folks, who (IIRC) don't have any of the
above.
Just thinking aloud. Thanks for your insight.
-JP
Seems like a zypper module is really the right way to go. Maybe some SLES folks would like to help out, though I should say Python is pretty easy to learn and we don’t use many of the scary bits.
BTW – Modules for the port system have been discussed and have a decent chance of happening.