Puppet users - Jul 2013 - Module team update: 2013-07-07 - 2013-07-12

Hello!

Now that we''re two weeks in it''s time for another update on
what''s been
going on in the module team.  We focused on puppetlabs-ntp and
puppetlabs-firewall as our two primary modules, but also merged in fixes to
passenger, rabbitmq, mysql, apt, and apache.

As a result of this work we''ve released:

http://forge.puppetlabs.com/puppetlabs/apache/0.7.0
http://forge.puppetlabs.com/puppetlabs/ntp/1.0.0
http://forge.puppetlabs.com/puppetlabs/firewall/0.4.0

Of these three the apache release is by far the largest.  The module was
basically rewritten between the older version and this and most users have
been using it from git for a while.  This is a huge change so I would
recommend anyone on 0.6.0 to test carefully before unleashing it in
production.

The NTP module was also completely rewritten (but is tiny in comparison).
 There''s some work left to do in this to unify the templates but I
wanted
to get a release out the door today and work on the unification for 2.0.0.

The firewall changes are smaller but the regular mix of features and
bugfixes.

In addition to all these module releases Hunter released
http://rubygems.org/gems/rspec-system-serverspec, which is a bridge between
the serverspec matchers and rspec-system.

I made https://github.com/puppetlabs/puppetlabs-rabbitmq/pull/71 which is
an in progress refactor of the installation part of the rabbitmq module.  I
want to continue overhauling this module completely until it sparkles.
 Please take a poke in there and comment if you''re a rabbitmq user.


Thanks,

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

I insist on the question since I''ve not had answers previously:
Any hope the redesign of the PuppetLabs modules will consider the suggested 
standards discussed here:
https://github.com/stdmod/puppet-modules/blob/master/Parameters_List.md
?

On Saturday, July 13, 2013 12:24:46 AM UTC+2, Ashley Penney
wrote:
>
> Hello!
>
> Now that we''re two weeks in it''s time for another update
on what''s been
> going on in the module team.  We focused on puppetlabs-ntp and 
> puppetlabs-firewall as our two primary modules, but also merged in fixes to
> passenger, rabbitmq, mysql, apt, and apache.
>
> As a result of this work we''ve released:
>
> http://forge.puppetlabs.com/puppetlabs/apache/0.7.0
> http://forge.puppetlabs.com/puppetlabs/ntp/1.0.0
> http://forge.puppetlabs.com/puppetlabs/firewall/0.4.0
>
> Of these three the apache release is by far the largest.  The module was 
> basically rewritten between the older version and this and most users have 
> been using it from git for a while.  This is a huge change so I would 
> recommend anyone on 0.6.0 to test carefully before unleashing it in 
> production.
>
> The NTP module was also completely rewritten (but is tiny in comparison). 
>  There''s some work left to do in this to unify the templates but I
wanted
> to get a release out the door today and work on the unification for 2.0.0.
>
> The firewall changes are smaller but the regular mix of features and 
> bugfixes.
>
> In addition to all these module releases Hunter released 
> http://rubygems.org/gems/rspec-system-serverspec, which is a bridge 
> between the serverspec matchers and rspec-system.
>
> I made https://github.com/puppetlabs/puppetlabs-rabbitmq/pull/71 which is 
> an in progress refactor of the installation part of the rabbitmq module.  I
> want to continue overhauling this module completely until it sparkles. 
>  Please take a poke in there and comment if you''re a rabbitmq
user.
>
>
> Thanks,
>
-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

On Sat, Jul 13, 2013 at 6:16 AM, Alessandro Franceschi <al@lab42.it>
wrote:
> I insist on the question since I''ve not had answers previously:
> Any hope the redesign of the PuppetLabs modules will consider the
> suggested standards discussed here:
> https://github.com/stdmod/puppet-modules/blob/master/Parameters_List.md
> ?
>
I know you''re finding the lack of answer from us frustrating and I can
promise we''re not trying to ignore it or trivialize the issue.  From
our
perspective it''s just the two of us and we''re just trying to
find our feet
and handle the enormous PR backlog and get the modules into some kind of
shape.  I''m not against any of those parameter names and I''ll
accept PRs to
deprecate all the existing names and replace them with alternatives but
it''s just a big chunk of work that we haven''t been able to
schedule yet.

So from my personal point of view I am trying to use those parameter names
as much as possible, as well as that general class outline, in the context
of transforming existing modules where I can''t just start over.  We
haven''t
reached the point where we''re doing much from scratch so these kinds of
design things haven''t come up as we''re trying to find ways to
work within
what we got!

So there''s a totally unofficial answer, but I think hunner is generally
on
the same page as me.  We see the need for a standardized list of parameter
names/layout that is recommended, and we''re in favor of moving towards
it.

Alessandro, here''s a proposal that might help -
https://github.com/puppetlabs/puppet/pull/1718 is a PR about improving the
skeleton that module generate creates.  It would be awesome to see if we
can get electrical and you to work together to put together a skeleton that
a/ reflects the class layout in that doc (probably just
install,config,service and init as a skeleton) as well as a STANDARDS.md or
GUIDELINES.md document that includes all those parameters.  That way the
information would be right there whenever a user creates a module.

It would go a huge way towards getting these adopted I think if you
integrated that document directly into the module skeleton.  It would make
it easy for busy people like me juggling modules to constantly refer to the
document as I''d have copies of it all over the place. :)

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

On Saturday, July 13, 2013 2:47:36 PM UTC+2, Ashley Penney
wrote:
>
> On Sat, Jul 13, 2013 at 6:16 AM, Alessandro Franceschi
<a...@lab42.it<javascript:>
> > wrote:
>
>> I insist on the question since I''ve not had answers
previously:
>> Any hope the redesign of the PuppetLabs modules will consider the 
>> suggested standards discussed here:
>> https://github.com/stdmod/puppet-modules/blob/master/Parameters_List.md
>> ?
>>
>
> I know you''re finding the lack of answer from us frustrating and I
can
> promise we''re not trying to ignore it or trivialize the issue. 
From our
> perspective it''s just the two of us and we''re just trying
to find our feet
> and handle the enormous PR backlog and get the modules into some kind of 
> shape.  I''m not against any of those parameter names and
I''ll accept PRs to
> deprecate all the existing names and replace them with alternatives but 
> it''s just a big chunk of work that we haven''t been able
to schedule yet.
>
> So from my personal point of view I am trying to use those parameter names 
> as much as possible, as well as that general class outline, in the context 
> of transforming existing modules where I can''t just start over. 
We haven''t
> reached the point where we''re doing much from scratch so these
kinds of
> design things haven''t come up as we''re trying to find
ways to work within
> what we got! 
>
> So there''s a totally unofficial answer, but I think hunner is
generally on
> the same page as me.  We see the need for a standardized list of parameter 
> names/layout that is recommended, and we''re in favor of moving
towards it.
>
> Alessandro, here''s a proposal that might help - 
> https://github.com/puppetlabs/puppet/pull/1718 is a PR about improving 
> the skeleton that module generate creates.  It would be awesome to see if 
> we can get electrical and you to work together to put together a skeleton 
> that a/ reflects the class layout in that doc (probably just 
> install,config,service and init as a skeleton) as well as a STANDARDS.md or
> GUIDELINES.md document that includes all those parameters.  That way the 
> information would be right there whenever a user creates a module.
>
Wow, that''s what I call a direct approach, pushing a PR directly on
puppet
code to set "standards de facto"... wonder what some persons on this
list
would say about that (John?).
I still think that trying to find a shared agreement on naming standards is 
a step to do before pushing the whole default layout of puppet module 
generate.
Anyway I''ll gladly accept your invitation to prepare a  STANDARDS.md
and a
module skeleton PR , but, really , I think some (not so many actually) 
naming patterns still need discussion (package or package_name?) as in some 
cases I''ve deliberately introduced them (dependency_class?
options_hash?
user_class? install_*? monitor_* ? firewall_*?... ) and even if they make a 
lot of sense for me it might not be the same for others.
 
>
> It would go a huge way towards getting these adopted I think if you 
> integrated that document directly into the module skeleton.  It would make 
> it easy for busy people like me juggling modules to constantly refer to the
> document as I''d have copies of it all over the place. :)
>
Any place suggested by PuppetLabs on where to define modules standards is 
ok for me.
If the discussion can be done directly on the relevant PR, it''s ok for
me
too.

Thank you for the reply, 
Al
 

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

On Sat, Jul 13, 2013 at 11:26 AM, Alessandro Franceschi <al@lab42.it>
wrote:
> Any place suggested by PuppetLabs on where to define modules standards is
> ok for me.
> If the discussion can be done directly on the relevant PR, it''s ok
for me
> too.
>
Hi Al, I agree that the pattern itself needs more collaboration before it
starts getting applied to Puppet Labs modules. That said, you''ve got a
more
appropriate thread going for that discussion already (on Puppet-Users) and
I look forward to continuing it there.


-- 
Ryan Coleman | Modules & Forge | ryanycoleman on twitter & #puppet IRC

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

On 2013-07-13 20:26, Alessandro Franceschi wrote:
> Wow, that''s what I call a direct approach, pushing a PR directly
on
> puppet code to set "standards de facto"... wonder what some
persons on
> this list would say about that (John?).
> I still think that trying to find a shared agreement on naming standards
> is a step to do before pushing the whole default layout of puppet module
> generate.
> Anyway I''ll gladly accept your invitation to prepare a
STANDARDS.md and
> a module skeleton PR , but, really , I think some (not so many actually)
> naming patterns still need discussion (package or package_name?) as in
> some cases I''ve deliberately introduced them (dependency_class?
> options_hash? user_class? install_*? monitor_* ? firewall_*?... ) and
> even if they make a lot of sense for me it might not be the same for
others.
You don''t have to push all at once. I think the resource_ensure pattern
seems to be well accepted, even if some details might still require more 
hashing out/experimenting.

Establishing the discussion at the "source" (pardon the pun) will also
help to get the broadest exposure to the topic.


Regards, David

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.