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. - 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/-/x3A42LQ8ThgJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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 >-- 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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, Jun 28, 2012 at 2:46 PM, Steve Traylen <steve.traylen@cern.ch> wrote:> 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.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-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en.-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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.belanger@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. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, Jun 28, 2012 at 4:38 PM, Paul Belanger <paul.belanger@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.belanger@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. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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 -- 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/-/cHP2ASaukxcJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Sun, Jul 1, 2012 at 12:58 PM, Ken Dreyer <ktdreyer@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 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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 On Monday, July 2, 2012 11:33:42 PM UTC-4, Ryan Coleman wrote:> > On Sun, Jul 1, 2012 at 12:58 PM, Ken Dreyer <ktdr...@ktdreyer.com<javascript:>> > 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 >-- 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/-/VN72ADYnUP0J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, Aug 16, 2012 at 11:05 AM, Mark Roggenkamp <mark.roggenkamp@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. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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 On Thursday, August 16, 2012 2:35:57 PM UTC-4, Ryan Coleman wrote:> > On Thu, Aug 16, 2012 at 11:05 AM, Mark Roggenkamp > <mark.ro...@gmail.com <javascript:>> 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. >-- 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/-/tnJ4P-GWIgEJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.