On Tuesday, May 21, 2013 12:27:28 PM UTC-5, Jonathan Proulx wrote:
One of the most frustrating things about puppet is duplicate definitions
of packages,
The "ensure_packages" function from stdlib seems very much like the
correct way to handle this:
newfunction(:ensure_packages, :type => :statement, :doc => <<-EOS
Takes a list of packages and only installs them if they don't already
exist.
EOS
) do |arguments|
Why isn't this a core feature? Or better why aren't resources that are
identical merged? Clearly there is a conflict if they are defined with
different parameter (ensure => installed -vs ensure => latest for example)
but if they are really identical where is the conflict?
This topic has come up before. You will probably find a lot of discussion
about it under the heading of "module compatibility".
Anyway, where resources are indeed identical, I see no inherent harm in
merging them. Your manifest set would become more brittle the more it
relied on such merging, but I suspect the feature would have nevertheless
been implemented already if it were easy to do. I can think of several
reasons why it might actually be tricky to do this.
My current situation is that we define parted and xfsprogs in our local
site configs and the enovance ceph modules also do so. Both of these seem
reasonable to me as we need them to make all our systems go and the ceph
module needs them to set up the object storage volumes (which is it's
primary function) and can't assume everyone uses parted and xfs.
The two prevailing opinions in my web readings seem to be to use Virtual
resources which is fine for local modules but not so good for sharing and
the purist opinion that if there is a conflict the conflicting parts should
be split out into an independent module, which is fine for large functional
chunks like httpd but ridiculous for single utilities that require no
configuration.
The key factor here is that you very much (should) want a single
authoritative source describing each managed resource. *That* is what you
get by putting it in a separate module on which all others that need the
resource rely. I don't find that ridiculous at all, given how lightweight
modules are, but if it made you feel better then you could plan for a
single module with which to meet many such needs.
Using virtual resources also gives you a single authoritative source, but
it leaves open the question of to which module the resource should belong.
Indeed, it might not be unreasonable to make virtual *and* put it into a
separate module. Whether use of virtual resources across module boundaries
is conducive to sharing matters only if you are planning to share.
The simple fact that two modules both depend on the same resource, but
cannot either one depend on the other module, indicates to me that the
resource in question does not belong in either module. It is a question of
accurately modeling the target configuration space, and how large or small
the resulting classes and modules end up being is at best a secondary
consideration. If you use crude models, then you are likely to encounter
problems from time to time, and that's exactly what is happening to you now.
Yet there is little discussion of ensure_packages as an alternative. Is
this for cause or just because it is not well known?
It is at least partly because ensure_packages() is little known. It may
also be because ensure_packages() is itself a crude tool, susceptible to
producing inconsistent configurations for different machines and/or over
time, and applicable only to Package resources. It is worse than merging
identical resource declarations, because it will hide even non-identical
declarations of the same resource. If you use it then it is highly likely
to take a chunk out of your gluteus maximus sometime in the future.
John
