On Friday, March 28, 2014 10:14:56 AM UTC-5, Mike Frisch wrote:
>
> I am surprised there is no viable solution to this seemingly basic
> problem... I maintain a comprehensive set of Puppet modules for our
> internal software and while it hasn't been an issue yet, having two modules
> attempt to install the same package (ie. openssh-clients on RHEL) is
> certainly not out of the question. For my own maintained modules, this
> isn't a problem, but if I incorporate a third-party module that does the
> same, there's no guarantee that one of us won't have to change.
>
>
It is a basic problem in the sense that it is reasonably likely to be
encountered if you rely on an uncurated collection of modules or on modules
from multiple collections. It breaks modularity in that modules cannot be
implemented wholly without consideration of other modules. But be sure to
recognize that the problem is deeper than duplicate resource definition: it
goes to the *reason* that Puppet disallows duplicate declarations in the
first place.
Most resources -- and packages in particular -- are more complicated than a
binary absent/present (a.k.a defined) switch can capture. The "if !
defined" approach, including functions such as ensure_resource(), can
prevent Puppet from emitting duplicate declaration errors if used
pervasively, but it prevents Puppet from diagnosing conflicting resource
requirements. Consider this:
class site::security {
if ! defined Package['vino'] {
package { 'vino': ensure => 'absent' }
}
}
class myapp::dependencies {
if ! defined Package['vino'] {
package { 'vino': ensure => 'installed' }
}
}
Now suppose one of my nodes declares both classes. Puppet will not
complain, neither during catalog compilation nor during catalog
application, but it's anybody's guess whether vino will be installed or not
when Puppet is done. And it might go back and forth over time as the
manifest set is maintained.
To be sure, I chose the installed/absent conflict as a particularly
striking one, but the same principle applies to any other difference
between resource properties declared in different places. (For example, if
one of two or more declarations of one package specifies a version, and
another specifies a different version or none.)
> I have started using ensure_resource() but notice that with a Package
> resource that "ensure => installed" and "ensure => present" are treated as
> two distinct instantiations of the Package resource, even if they're
> treated as equivalent in Puppet.
>
>
Ensure_resource() is evil. Do not use it. Och's solution is one of the
better alternatives, because it avoids multiple declaration of any resource
(without regard to conditionals). The other reasonably good approach is
what Nigel suggested back in this thread's first life: factor out the
package in question into a separate module (where it is declared
concretely), and everywhere declare the appropriate class instead of
directly declaring the package.
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/7c80a861-3f48-4ae4-8ec5-91b82f99ebfa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
