ensure_packages is not low risk, IMO.
In testing, the following will result in a Duplicate declaration error:
$packages = ['wget']
package { $packages:
ensure => 'installed',
}
ensure_packages($packages)
Ensure_packages will not create a resource conflict with another instance
of ensure_packages. But, it will create a resource conflict with a
conventional package declaration. This is only a very slight improvement
over other approaches to in-module package dependency management.
If your 3rd party forge module uses ensure_packages to manage a dependency,
and I've setup a module to manage those dependencies using conventional
package resources, your module will conflict with my module.
Regards,
Chris
On Thursday, May 23, 2013 11:42:39 PM UTC-7, David Schmitt wrote:
>
> On 2013-05-22 16:00, jcbollinger wrote:
> >
> >
> > On Wednesday, May 22, 2013 1:48:26 AM UTC-5, David Schmitt wrote:
> >
> >
> > 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.
> >
> >
> > No, the only resource types that could have no-parameter use cases would
> > be those with no parameters, but there are none such. Some types,
> > including Package, admit sensible use cases involving only default
> > parameter values, but that's a rather different thing, and not
> > necessarily the thing you want. Also, either ensure_packages() must
> > ignore the context-specific Package parameter defaults (in which case
> > those won't work, which could be a hard-to-debug surprise) or else uses
> > of the function in different contexts can be inequivalent, so that one
> > set of package parameters is chosen over all others, at semi-random
> > (also a potential nasty surprise).
> >
> > Furthermore, ensure_packages() is inherently parse-order dependent, and
> > parse-order dependencies are a major source of concern in Puppet
> > manifest design. That is mitigated in this case if you require that
> > packages used with ensure_packages() are never declared any other way,
> > but then you're placing a constraint on your manifest set that is easy
> > to overlook, that might not be enforced by the catalog compiler, and
> > that you cannot by any means expect third-party modules to comply with.
> >
> > Ensure_packages() is bad juju. If you design your manifest set well in
> > the first place then you will not need it. Sadly, the current state of
> > module compatibility is that in some cases you may need to refactor
> > third-party modules to achieve the overall design criteria you want. At
> > least Puppet will notify you of those cases (provided that
> > ensure_packages() or some similar device doesn't mask it).
>
> I totally agree with your sentiment in theory, but would like to note
> that in practice, "ensure_package('wget')" is an efficient and low-risk
> way to solve a real problem across otherwise non-cooperating modules.
>
> Please also note, that in my years of module writing, I only encountered
> a handful of packages that should be given this treatment. Wget and
> rsync being the most prominent of those.
>
>
> 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 view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/576f8fbb-662f-4f06-a073-67c96df7a6e8%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
