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 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
