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).


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.


Reply via email to