On Tue, 21 May 2013 13:27:28 -0400, Jonathan Proulx <j...@jonproulx.com> 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? > > 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. > > Yet there is little discussion of ensure_packages as an alternative. Is > this for cause or just because it is not well known?
Just because it is not well known. ensure_packages seems to be designed for exactly the use-case you are describing: you have two modules both requiring the same utility packages without caring at all about versions or anything else. To elaborate: contrary to (most, all?) other resources, packages have this no-parameter use case, which allows conflict-free merging. Managing more complex resources (users, files) would require more cooperation between modules to ensure that the different requirements do not step on each other. Regards, David -- 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.
