Re: packaging puppet modules

[Steve Traylen]

On Thursday, 28 June 2012 14:57:08 UTC+2, Ken Dreyer wrote:

Hi Puppet folks,

I'm a Fedora packager, and I'm looking into packaging up some of the modules at http://forge.puppetlabs.com/users/puppetlabs

I'm thinking through the naming scheme for modules. It looks like the upstream modules include the creators' names as part of the package names, which strikes me as a little verbose from the perspective of Fedora packaging.

For example, the Puppetlabs' mysql module RPM  would (in theory) be called "puppetmodule-puppetlabs-mysql". That's a mouthful. Any chance we could have the Puppet Labs' modules be considered "canonical" modules on the Forge, and then strip away the puppetlabs vendor name? Any other ideas welcome.

Presumably it would end up on the filesystem as something like $modulepath/mysql/.... so the puppetlabs bit is a bit redundant

in some ways. Ignore packages for now, how does anyone cope with 'puppetlabs-mysql' and 'whatever-mysql'... in the same environment.

 

- Ken

[Brian Gupta]

We don't, because the pattern seems to be to dump the leading
identifiers in the repo name, and many modules assume their namespace
is just the service/package name they are managing, e.g. modules/mysql.
If you look in init.pp in the case of the puppetlabs' mysql module,
this is clear as the main class is just called mysql. The way we deal
with these typically is to standardize on a single module and install
it as a git submodule. I believe if you wanted more than one, you
would need to make changes to the code. (We don't use the mysql
module, but it is a good example.)

So:
cd $puppetgitworkingdir
git submodule git://github.com/puppetlabs/puppetlabs-mysql.git modules/mysql
git submodule init
git submodule update

Cheers,
Brian

>>
>> - Ken
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/HZDPZSyjbSEJ.
>
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.

[Paul Belanger]

On 12-06-28 08:57 AM, Ken Dreyer wrote:
> Hi Puppet folks,
>
> I'm a Fedora packager, and I'm looking into packaging up some of the
> modules at http://forge.puppetlabs.com/users/puppetlabs
>
> I'm thinking through the naming scheme for modules. It looks like the
> upstream modules include the creators' names as part of the package names,
> which strikes me as a little verbose from the perspective of Fedora
> packaging.
>
> For example, the Puppetlabs' mysql module RPM would (in theory) be called
> "puppetmodule-puppetlabs-mysql". That's a mouthful. Any chance we could
> have the Puppet Labs' modules be considered "canonical" modules on the
> Forge, and then strip away the puppetlabs vendor name? Any other ideas
> welcome.
>

I'm considering doing the same for Debian. I haven't researched a
naming scheme yes however I would expect something like
puppetmodule-puppetlabs-mysql or puppet-module-puppetlabs-mysql would apply.

I'd be reluctant to call it puppet-module-mysql unless it was actually
bundled within puppet.

--
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.b...@polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter:
https://twitter.com/pabelanger

[Brian Gupta]

On Thu, Jun 28, 2012 at 4:38 PM, Paul Belanger
<paul.b...@polybeacon.com> wrote:
> On 12-06-28 08:57 AM, Ken Dreyer wrote:
>>
>> Hi Puppet folks,
>>
>> I'm a Fedora packager, and I'm looking into packaging up some of the
>> modules at http://forge.puppetlabs.com/users/puppetlabs
>>
>> I'm thinking through the naming scheme for modules. It looks like the
>> upstream modules include the creators' names as part of the package names,
>> which strikes me as a little verbose from the perspective of Fedora
>> packaging.
>>
>> For example, the Puppetlabs' mysql module RPM  would (in theory) be called
>> "puppetmodule-puppetlabs-mysql". That's a mouthful. Any chance we could
>> have the Puppet Labs' modules be considered "canonical" modules on the
>> Forge, and then strip away the puppetlabs vendor name? Any other ideas
>> welcome.
>>
> I'm considering doing the same for Debian.  I haven't researched a naming
> scheme yes however I would expect something like
> puppetmodule-puppetlabs-mysql or puppet-module-puppetlabs-mysql would apply.
>
> I'd be reluctant to call it puppet-module-mysql unless it was actually
> bundled within puppet.

In the Debian world I'd consider a metapackage (hope this is the right
term) callet puppet-module-mysql, that can be install package
alternatives, and have puppet-module-puppetlabs-mysql (or something
like that) be one of possibly many alternatives.

I think the bigger question is whether Puppetlabs (via puppet forge)
considers best practice to have multiple modules supporting the same
service to be either/or alternatives, or wants people to make modules
that can be coexist in parallel. In my limited experience working with
people's third party modules, there seems to be an assumption that a
given module will be the only module on a given
puppetmaster/modulepath that is capable of managing a given
service/package, but I don't know if this is a published standard or
just people not thinking folks might want to have two modules managing
the same resource installed at the same time.

>
> --
> Paul Belanger | PolyBeacon, Inc.
> Jabber: paul.b...@polybeacon.com | IRC: pabelanger (Freenode)
> Github: https://github.com/pabelanger | Twitter:
> https://twitter.com/pabelanger
>
>

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.

[Ken Dreyer]

On Thursday, June 28, 2012 2:47:10 PM UTC-6, Brian Gupta wrote:

In the Debian world I'd consider a metapackage (hope this is the right
term) callet puppet-module-mysql, that can be install package
alternatives, and have puppet-module-puppetlabs-mysql (or something
like that) be one of possibly many alternatives.

Interesting idea with alternatives; I'll give that some thought. I seem to remember that sometimes the depsolving doesn't always do the right thing, but maybe that is indeed the most future-proof solution.

Like you mentioned, I too would like to hear more from Puppet Labs' staff on where they see the Module culture going.

- Ken

[Ryan Coleman]

On Sun, Jul 1, 2012 at 12:58 PM, Ken Dreyer <ktdr...@ktdreyer.com> wrote:
> Like you mentioned, I too would like to hear more from Puppet Labs' staff on
> where they see the Module culture going.

Hi everyone, sorry for the tardy reply. I wanted to see what everyone
had to say before 'weighing in'.

My answer to this is a bit complicated but I'll try to be succinct. As
you deduced Ken, modules on the Puppet Forge are name-spaced as
author-module_name. A module installed into ones modulepath strips
away author and leaves module_name. So if you were going to package
them (and please feel free to!), you'd be looking at something like
puppetmodule-puppetlabs-mysql for our MySQL module. Yep, it looks a
bit silly but becomes less so when you look at non-PL modules. For
instance, puppetmodule-rcoleman-mysql makes a lot more sense.

Doing something like Debian alternatives is an interesting idea but
isn't something feasible today. If Puppet Labs produces
puppetlabs-mysql and I produce rcoleman-mysql, you as the consumer
have zero assurance that they provide the same functionality. The
Puppet Labs variant could manage the full stack while mine could just
install the package. If we were in a situation where we could describe
a modules functionality in factual terms to automatically make claims
about whether two MySQL modules are equivalent, perhaps this could
work but that's not something we can do nor do I see being possible in
the platform anytime soon.

On the other hand, once you get to a point where you can say the
Puppet Labs MySQL module and the rcoleman MySQL module provide the
same functionality, why bother having two? I'd much rather see the
module community coalesce around modules that claim to do similar
things, combine ideas from different groups and offer everyone one or
two modules that do a thing very well. In that scenario, everyone gets
the functionality they want and packaging becomes a less complicated
chore. Namespace is still important so that core authors can be
credited and everyone has an opportunity to put their module ideas out
there. The core set of high-quality modules don't even have to be in
the Puppet Labs namespace. Remember, we know Puppet, not all the
various applications you use and expertly manage.

Realistically, I intend to make an effort to encourage module
consolidation and collaboration and perhaps we can have some sort of
community ratings and review process to let the cream rise to the top,
identify the tasty, creamy modules and make those the ones that get
packaged by persons such as yourself.

As always, we welcome your input and just want to enable those
crafting modules and those consuming them to manage infrastructure and
solve problems.

--Ryan

[Mark Roggenkamp]

Is this level of namespacing enough? 

What happens when a module (mymodule) depends on the "mysql" module but you chose a mysql module that isn't quite the same as the one mymodule expects?

Thanks

Mark

[Ryan Coleman]

On Thu, Aug 16, 2012 at 11:05 AM, Mark Roggenkamp
<mark.ro...@gmail.com> wrote:
> What happens when a module (mymodule) depends on the "mysql" module but you
> chose a mysql module that isn't quite the same as the one mymodule expects?

Your module would depend on a specific mysql module though, right?
mymodule depends on someuser-mysql for example.

When you're authoring your own content, you'll have to make a decision
about which users mysql module meets your needs and aligns with how
you view the world. We don't have great tooling on the Forge to help
you make that decision but we'll be rectifying that.

[Mark Roggenkamp]

Yeah, I'm saying you probably have a specific mysql module in mind and it seems the only way that dependency is specific enough is through the Modulefile. 

In my manifest I'd just say "include mysql". There's no mechanism in the language itself for deciphering between someuser-mysql and someuser2-mysql, right? It seems the only thing that specifies the difference is the Modulefile and thus the puppet module tool.

What if I choose someuser1-mysql for mymodule and then I later want another module on the forge that chose someuser2-mysql as it's dependency? Now if they don't have similar interfaces (not to mention implementations) I'm stuck, right?

Thanks

Mark