Hi Matt,

What I've seen done before is to use ${modulename}x for 'wrapper' modules
that give you the ability to stay current with the
forge/release/externally-owned module, but still maintain the necessary
site-spectific-shim code to extend the functionality of the original module
in the ways you desire.

We use the class 'mysqlx' as a place for a few defined types, and as a
namespacing entry point to hiera, which allows us to have  mysqlx::v5,
mysqlx::v55, and  mysqlx::v56 classes which all take the same parameters
that the puppetlabs-mysql class does. These namespacing classes can take
care of loading sane version-specific defaults from hiera for $version of
mysql, and subsequently feeding them to the puppetlabs-mysql module.

I've found this to work reasonably well thus far. Hope that helps.


On Mon, May 20, 2013 at 3:34 AM, Nikola Petrov <nikol...@gmail.com> wrote:

> Well we had that problem in the past. I now name my modules with a
> prefix for the company first letter so if I was working for puppetlabs
> then I would name the module pmysql. The thing is that most of the time
> I want convenient "wrappers" for the mysql module provided by puppetlabs
> or some third party. This also ensures that if they change the interface
> I have stable defines/classes.
>
> The other way arround this is to put all those things in a single module
> named "site" or "custom" for example.
>
> --
> Nikola
>
> On Thu, May 16, 2013 at 05:10:44PM -0500, Matt Zagrabelny wrote:
> > Greetings,
> >
> > When writing modules are people namespacing them to avoid collisions
> > with puppetlabs' modules?
> >
> > I wrote some (very simple) modules:
> >
> > mysql
> > postgresql
> >
> > that now have namespace conflicts when I am trying to install the
> > puppetlabs modules of the same name.
> >
> > Is there a best practice or style guide that people follow when
> > namespacing their in-house modules?
> >
> > For instance:
> >
> > site::umn::duluth::postgresql
> >
> > ??
> >
> > Thanks for any hints or feedback!
> >
> > -mz
> >
> > --
> > 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.
> >
> >
>
> --
> 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.
>
>
>

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