Re: [Puppet Users] package conflict resolution method:

Jason Antman
Wed, 20 Nov 2013 12:47:00 -0000

Matt,

I can''t speak for exactly what John was implying, but I''ve
been working
on something similar recently, and facing more or less the same problems
that you''re implying below, so I''ll give you my take on it.

1) Yes, it means factoring "all" possibly-shared resources out into
discrete classes. The definition of "all" is flexible depending on how
fine-grained your package management needs to be, and how willing you
are to possibly have some "extra" packages floating around.

2) Including modules from the Forge is another beast. At this point, at
$work, we''re moving in the direction of *only* writing our own modules
if there isn''t a suitable Forge module. So, we''ve ended up
with a few
cases where we have two conflicting modules that can''t be used on the
same node (usually a Forge module that is intended to replace an older
in-house module as it''s phased out).

The "proper" way to manage this is when you add a Forge module that
replaces existing functionality, you should remove any existing
declarations of those resources and replace them with a require, or
something like that.

A specific example... we recently started using the
puppetlabs-postgresql Forge module
(https://github.com/puppetlabs/puppetlabs-postgresql/). It has a
postgresql::lib::python class that installs the python-psycopg2 package
(the python postgres driver), and a postgresql::lib::devel class that
installs postgresql-devel. So, when we decided we were going to use the
new Forge module, we grepped through all of our existing modules, and
replaced any Package resources for these packages with "require
postgresql::lib::python" and "require postgresql::lib::devel",
respectively.

I assume I speak for many in saying that I hope that with the
ever-increasing usefulness of the Forge, the community begins to
converge on a single "canonical" module for a given use case or
package.

-jason antman

On 11/19/2013 02:48 PM, Matt Simmons wrote:
> Hi John,
>
> I''m new around here, but I''m also in the same situation
as Tom, who
> started this thread.
>
> I was wondering if you could expound a little bit on the better
> solution that you mention. I write what I could refer to as "third
> grade puppet", but I''d like to get better.
>
> When you suggest factoring out these resources into separate classes
> and modules, do you mean that, in essence, all possibly-shared
> resources should be in discrete modules or classes? How does that jive
> with modules included from Puppet Forge? Doesn''t that mean
refactoring
> everything you include there, as well?
>
> Thanks, and sorry for what I''m sure is an overly-basic question,
>
> --Matt Simmons
>
>
> --
> 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+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
>
https://groups.google.com/d/msgid/puppet-users/7f66b5b7-6e20-4835-a057-b62c1add08e7%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit