Fwd: [Module team] Much ado about modules

[Ashley Penney]

Hello!

Now that Puppetlabs has a module team we thought we should start trying to keep the community informed as to what we're doing and why on earth we're doing it.  I wanted to put together a short update (I'm aiming to do these every friday) as to where we stand.

This was our first week working full-time on Modules, and I spent a good chunk of time this week filling in paperwork, meeting people I've only seen on IRC, and trying to get up to speed with internal systems and tools.  This slowed us down a little.

We focused specifically on puppetlabs-mysql and puppetlabs-apt this week to try and get the PR/issue count under control.  To give you an idea of the progress we've made:

puppetlabs-mysql: Closed/merged 20 PRs.

puppetlabs-apt: Closed/merged 18 PRs.

We're going to continue iterating over different modules each week to deal with the enormous backlog of PRs and issues and keep bashing these into shape until we're caught up with all the community submissions.

We appreciate each and every PR you send us (unless you forgot specs, which makes me shout at a puppy) and hopefully we'll be able to shorten the cycle of merging them as this work goes forward.

As a result of this week's work we have released:

http://forge.puppetlabs.com/puppetlabs/apt/1.2.0

http://forge.puppetlabs.com/puppetlabs/mysql/0.8.0

Thanks,

[Nan Liu]

On Fri, Jul 5, 2013 at 11:05 AM, Ashley Penney <ashley...@puppetlabs.com> wrote:

Now that Puppetlabs has a module team we thought we should start trying to keep the community informed as to what we're doing and why on earth we're doing it.  I wanted to put together a short update (I'm aiming to do these every friday) as to where we stand.

This was our first week working full-time on Modules, and I spent a good chunk of time this week filling in paperwork, meeting people I've only seen on IRC, and trying to get up to speed with internal systems and tools.  This slowed us down a little.

Hi! I'm glad to hear this is prioritized.

We focused specifically on puppetlabs-mysql and puppetlabs-apt this week to try and get the PR/issue count under control.  To give you an idea of the progress we've made:

puppetlabs-mysql: Closed/merged 20 PRs.

puppetlabs-apt: Closed/merged 18 PRs.

We're going to continue iterating over different modules each week to deal with the enormous backlog of PRs and issues and keep bashing these into shape until we're caught up with all the community submissions.

We appreciate each and every PR you send us (unless you forgot specs, which makes me shout at a puppy) and hopefully we'll be able to shorten the cycle of merging them as this work goes forward.

As a result of this week's work we have released:

http://forge.puppetlabs.com/puppetlabs/apt/1.2.0

http://forge.puppetlabs.com/puppetlabs/mysql/0.8.0

Would it be possible for the module team to review Alessandro's "The handy grail of modules standards" thread and set a variable name standard moving forward? It doesn't even need to be quite as comprehensive, but some basic standard to start. We use quite a few modules as upstream, and would love to see some consistency even if it means breaking changes. Thanks again, and look forward to the great things coming out of the module team.

Nan

[William Van Hevelingen]

On Fri, Jul 5, 2013 at 11:05 AM, Ashley Penney <ashley...@puppetlabs.com> wrote:

Hello!

Now that Puppetlabs has a module team we thought we should start trying to keep the community informed as to what we're doing and why on earth we're doing it.  I wanted to put together a short update (I'm aiming to do these every friday) as to where we stand.

This is awesome I've been waiting for this to be prioritized as well. :)

 

We appreciate each and every PR you send us (unless you forgot specs, which makes me shout at a puppy) and hopefully we'll be able to shorten the cycle of merging them as this work goes forward.

Specs are really hard for first time contributors, a lot of Pull Requests are still in the backlog of unmerged PRs due to the submitter being asked to submit Spec tests. I would like to see some documentation we can point first time contributors too. The corresponding ticket is:

https://projects.puppetlabs.com/issues/14456

Also perhaps the new module team can make the final decision on:

https://projects.puppetlabs.com/issues/11118

Looking forward I would like to see Puppet modules development remove the bottleneck on Puppetlabs staff and other module maintainers to merge PRs. Often times I submit PRs for new OS support or additional features to really good modules on Github or the Forge and the maintainer does not have the time or OS to review, test and merge the PR.

A possible solution might be to mirror The Openstack Project. They have a pretty effective process of using Gerrit + Jenkins to review, test, and merge code.

The goal would be to allow us to have "community supported" official modules kind of like how the Nagios project has a nagios-plugins repo. I think a system like this or similar would allow us to:

 * Submit new modules for inclusion as "official community" modules

 * Support faster iteration on more operating systems

 * Reduce the number of competing modules on the forge, everyone doesn't need there own custom Apache module

 * Improve the quality of modules and increase the amount of testing

 * Reduce the number of "bad" modules on the Forge

I look forward to hearing people's ideas and continuing the discussion.

William

[Alessandro Franceschi]

+1 of course.

We all say some naming standards are needed and we still continue to make our modules in our ways.

For the sanity of Puppet modules ecosystem let's do something about it.

[Ashley Penney]

This is definitely something we want to do and need to do.  I've been a little hesitant to wade down into the whole "these are the specific parameter names we want to use" and building out a huge set of guidelines, but I do have a straightforward question for the list along these lines:

We're refactoring the ntp module to try and be a little bit of a better design rather than one giant class.  We've been having some discussions in the PR about the right way to name the following options:

manage_service

ensure_package

package_enable

I was leaning towards:

ensure_package

enable_package

ensure_service.

But it's been proposed that:

service_ensure

package_enable

Makes better sense in terms of being able to scan for things.

Does anyone reading this have strong preferences either way?  Now is the time for us to slowly start renaming parameters across the modules as we work on bringing in PRs, so speak up now. :)

[Alessandro Franceschi]

Please give a look to this:

https://github.com/stdmod/puppet-modules/blob/master/Parameters_List.md
it's basically the output of the (somehow limited, but well thought over) discussion about naming standards on 

https://docs.google.com/a/lab42.it/document/d/1D4OqEI5iuGJe63ODU91N6rnFKcxVAg1sAWbaQrGBlWA

It has for sure many more parameters that the ones you can expect in a module, but the point is always that you use the ones you need.

It tries to define some naming patterns for parameter, for cases where they are needed or would be nice to have.

I really would prefer that a common and shared discussion on a single parameters list could be done not only for PuppetLabs modules but for any module that somehow wants to follow a standard naming convention.

What about commenting / committing alternative lists directly on GitHub ?
(The repo is now under a generic stdmod GitHub organization, it can be moved anywhere, eventually under PuppetLabs organization, and, once completed,  remain a reference for naming standards)

[root]

Hello.  It would be nice if there was a way to browse all modules on Puppet Forge.  I can browse all the modules released by Puppet Labs @ http://forge.puppetlabs.com/puppetlabs, (same for any author for whom I know the username) but as far as I know, there is no way to browse all modules. (Perhaps there is with the Puppet Module Tool, but I can't get that to work through our proxy.)

 

Thanks.   

[Nan Liu]

On Mon, Jul 8, 2013 at 10:55 AM, root <clri....@gmail.com> wrote:

Hello.  It would be nice if there was a way to browse all modules on Puppet Forge.  I can browse all the modules released by Puppet Labs @ http://forge.puppetlabs.com/puppetlabs, (same for any author for whom I know the username) but as far as I know, there is no way to browse all modules. (Perhaps there is with the Puppet Module Tool, but I can't get that to work through our proxy.)

http://forge.puppetlabs.com/modules

Nan

[Nan Liu]

 I would agree with resource_attributes order instead of the other way around. It also makes sense because you can just introspect the class parameters with .sort and everything is in an easy to find order.

Thanks,

Nan

[root]

Ah, that workes nicely, thanks.

On Monday, July 8, 2013 2:02:46 PM UTC-4, Nan Liu wrote:

On Mon, Jul 8, 2013 at 10:55 AM, root <clri....@gmail.com> wrote:

 

http://forge.puppetlabs.com/modules

 

[David Schmitt]

On 08.07.2013 20:06, Nan Liu wrote:
> This is definitely something we want to do and need to do. I've
> been a little hesitant to wade down into the whole "these are the
> specific parameter names we want to use" and building out a huge set
> of guidelines, but I do have a straightforward question for the list
> along these lines:
>
> We're refactoring the ntp module to try and be a little bit of a
> better design rather than one giant class. We've been having some
> discussions in the PR about the right way to name the following options:
>
> manage_service
> ensure_package
> package_enable
>
> I was leaning towards:
>
> ensure_package
> enable_package
> ensure_service.
>
> But it's been proposed that:
>
> service_ensure
> package_enable
>
>
> I would agree with resource_attributes order instead of the other way
> around. It also makes sense because you can just introspect the class
> parameters with .sort and everything is in an easy to find order.

Indeed, the grouping by lexical order is one of the main arguments for
that. Also it mirrors the order in which the words are written in the
manifest:

class X { package { Y: ensure => present
=>
$X::[package_][Y_]ensure == present

Regards, David

[Alessandro Franceschi]

Given that https://github.com/stdmod/puppet-modules/blob/master/Parameters_List.md is based on the same resource_argument pattern can we make a step further and define names that can be used for any module and call them "suggested standards"?
Restricting the discussion to PuppetLabs modules only is a wasted occasion.

I don't want to be repetitive, but many people are saying that some naming standards are necessary and I personally think that the effort to define them is not great, being just a matter of defining (well thought) names that everybody can use.

my2c

--
You received this message because you are subscribed to a topic in the Google Groups "Puppet Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/ayYXxU3ft04/unsubscribe.
To unsubscribe from this group and all its topics, send an email to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet...@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[jcbollinger]

On Monday, July 8, 2013 11:02:25 AM UTC-5, Ashley Penney wrote:

This is definitely something we want to do and need to do.  I've been a little hesitant to wade down into the whole "these are the specific parameter names we want to use" and building out a huge set of guidelines, but I do have a straightforward question for the list along these lines:

We're refactoring the ntp module to try and be a little bit of a better design rather than one giant class.  We've been having some discussions in the PR about the right way to name the following options:

manage_service

ensure_package

package_enable

I was leaning towards:

ensure_package

enable_package

ensure_service.

But it's been proposed that:

service_ensure

package_enable

Makes better sense in terms of being able to scan for things.

Does anyone reading this have strong preferences either way?  Now is the time for us to slowly start renaming parameters across the modules as we work on bringing in PRs, so speak up now. :)

In an abstract sense, I think I prefer <component>_ensure over ensure_<component>, on the principle that the most-significant name component should come first.  It's not really about scanning for things for me, but rather about grouping related things together.  That carries advantages for visual scanning, but the grouping aspect is more fundamental.

In a more concrete sense, if you are naming parameters of a class, then the datum we abstractly refer to as <component>_ensure might more sensibly be named something else in that context.  For example, in a class ntp::service, I would certainly choose the parameter name "ensure" over "service_ensure".  There is therefore some dependency on module structure and intended use.


John

[Nikola Petrov]

+1

>
> In a more concrete sense, if you are naming parameters of a class, then the
> datum we abstractly refer to as <component>_ensure might more sensibly be
> named something else in that context. For example, in a class
> ntp::service, I would certainly choose the parameter name "ensure" over
> "service_ensure". There is therefore some dependency on module structure
> and intended use.

+1

NB: I can't remember the last time I agreed with someone on everything that
he says.

--
Nikola

[Alessandro Franceschi]

FYI, I've integrated this suggestion, and other de facto standards in:

https://github.com/stdmod/puppet-modules/blob/master/Parameters_List.md