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+unsubscribe@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.
On Thursday, May 16, 2013 5:10:44 PM UTC-5, Matt Zagrabelny wrote:> > Greetings, > > When writing modules are people namespacing them to avoid collisions > with puppetlabs'' modules? >Typically not.> > 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? >Not that I know of. Prevailing opinion seems to be that you should choose one module to manage each type of subsystem for all nodes in your site, or at least for all nodes in any given environment. If you follow that practice then a name collision highlights a poor choice of names for one module or another. On the other hand, there''s a slightly-different question involving modules and classes providing *extra*, site-specific configuration and/or customization for one subsystem or another. Personally, I am inclined to put such stuff into classes in a ''site'' module. E.g. "site::mysql". Inasmuch as such a module provides site-specific declarations and data, it''s not much of a stretch after all to say that putting its contents into generically named modules, such as "mysql", would constitute a poor naming choice. 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+unsubscribe@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.
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+unsubscribe@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+unsubscribe@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.
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 <nikolavp@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+unsubscribe@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+unsubscribe@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+unsubscribe@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.