Puppet users - May 2011 - Going to publish custom modules : Request for comments

Hi,

I''ve been using puppet for a while now, and over time I''ve
created many
classes and definitions for a whole bunch of different things.
It''s all very RHEL4, RHEL5 (and now RHEL6) centric, but since lots of
people use that (or clones like CentOS), I''m sure it could all be
reused
by many. The license will be Apache 2.0, just like puppet itself.

Most of my ugly-ish code has already been cleaned up as modules, but in
order to release something really easy to be reused, I''m now looking
into the best way to document everything cleanly. The obvious choice
seems to be using puppetdoc, so I''ve started with a simple xinetd
module I had, making all of the relevant changes, and here is the
result :

https://github.com/thias/puppet-modules

Comments about what I''m doing right and what I''m doing wrong
would be
very welcome. I really want to know that everything''s optimal before
investing time in publishing more modules, to not have to later waste
time going over all modules again.

If there are people familiar with puppetdoc here : Is it possible to
generate clean doc for my modules with only relative links to be
included in the repo? My testing with 0.25.5 (don''t ask...)
isn''t going
so well.

Matthias

-- 
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 Sun, May 15, 2011 at 7:34 AM, Matthias Saou <
thias@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net> wrote:
> Hi,
>
> I''ve been using puppet for a while now, and over time
I''ve created many
> classes and definitions for a whole bunch of different things.
> It''s all very RHEL4, RHEL5 (and now RHEL6) centric, but since lots
of
> people use that (or clones like CentOS), I''m sure it could all be
reused
> by many. The license will be Apache 2.0, just like puppet itself.
>
> Most of my ugly-ish code has already been cleaned up as modules, but in
> order to release something really easy to be reused, I''m now
looking
> into the best way to document everything cleanly. The obvious choice
> seems to be using puppetdoc, so I''ve started with a simple xinetd
> module I had, making all of the relevant changes, and here is the
> result :
>
> https://github.com/thias/puppet-modules
>
> Comments about what I''m doing right and what I''m doing
wrong would be
> very welcome. I really want to know that everything''s optimal
before
> investing time in publishing more modules, to not have to later waste
> time going over all modules again.
>
The code is very easy to read and understand (which is one of the most
important criteria)

I have an implementation question:

1. Why are you doing the chkconfig exec:

        exec { "chkconfig ${title} on":
            notify => Service["xinetd"],
            path   => [ "/sbin", "/bin" ],
            onlyif => "chkconfig --list ${title} | egrep -q
''off$''",
        }


why doesnt:

service { $title:
  enable => ''true''
}

work for this?


If there are people familiar with puppetdoc here : Is it possible
to
> generate clean doc for my modules with only relative links to be
> included in the repo?

I do not understand this question.

> My testing with 0.25.5 (don''t ask...) isn''t going
> so well.
>
> Matthias
>
> --
> 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.

Dan Bode <dan@puppetlabs.com> wrote:

[...]
> > Comments about what I''m doing right and what I''m
doing wrong would
> > be very welcome. I really want to know that everything''s
optimal
> > before investing time in publishing more modules, to not have to
> > later waste time going over all modules again.
> >
> 
> The code is very easy to read and understand (which is one of the most
> important criteria)
Thanks. And I completely agree about the importance of readability :-)
> I have an implementation question:
> 
> 1. Why are you doing the chkconfig exec:
> 
>         exec { "chkconfig ${title} on":
>             notify => Service["xinetd"],
>             path   => [ "/sbin", "/bin" ],
>             onlyif => "chkconfig --list ${title} | egrep -q
''off$''",
>         }
> 
> 
> why doesnt:
> 
> service { $title:
>   enable => ''true''
> }
> 
> work for this?
Fair question. I''m guessing that I assumed initially that the xinetd
"sub-services" wouldn''t work with the puppet provider.
I''m now guessing
that I should do some testing again and simplify this accordingly.

Thanks for the feedback : Exactly the kind I was ultimately looking for
by releasing my modules to the public! :-)
> If there are people familiar with puppetdoc here : Is it possible to
> > generate clean doc for my modules with only relative links to be
> > included in the repo?
> 
> I do not understand this question.
Let me rephrase quickly : From a checkout inside ~/puppet-modules/ when
I run something like this :
puppetdoc --mode rdoc --outputdir ./doc \
  --modulepath modules --manifestdir /var/empty

I then get html documentation inside ./doc/ but all of the manifests
files are referred to as /home/myuser/puppet-modules which would be
quite ugly if included in the git repo or on a website as documentation.

I''ve just tested with 2.6.8 and I still get the same result. There are
more details, like the module''s main class showing up as xinetd::xinetd
instead of just xinetd or my definition''s parameters needing to be
right after the "define" line (no empty line in between allowed) or
the
documented #-- not working to stop further parsing...

Are others using puppetdoc for their modules? Are there some good
examples out there? The official documentation is useful but seems
somewhat limited.

Matthias

-- 
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 15 May 2011 20:27, Matthias Saou <
thias@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net> wrote:
> Dan Bode <dan@puppetlabs.com> wrote:
>
> > I have an implementation question:
> >
> > 1. Why are you doing the chkconfig exec:
> >
> >         exec { "chkconfig ${title} on":
> >             notify => Service["xinetd"],
> >             path   => [ "/sbin", "/bin" ],
> >             onlyif => "chkconfig --list ${title} | egrep -q
''off$''",
> >         }
> >
> >
> > why doesnt:
> >
> > service { $title:
> >   enable => ''true''
> > }
> >
> > work for this?
>
> Fair question. I''m guessing that I assumed initially that the
xinetd
> "sub-services" wouldn''t work with the puppet provider.
I''m now guessing
> that I should do some testing again and simplify this accordingly.
>
Isn''t the difference that IF the service doesn''t exist then it
won''t fail,
whereas the standard service enable definition will need to service to
exist? Unless I''m missing something in the bigger picture, this is an
area,
only doing stuff if the files are there to have stuff done upon them, where
puppet seems to fall short.

Thanks

Chris

-- 
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 Sun, 2011-05-15 at 21:27 +0200, Matthias Saou wrote:
> Dan Bode <dan@puppetlabs.com> wrote:
> > [snip]
> > If there are people familiar with puppetdoc here : Is it possible to
> > > generate clean doc for my modules with only relative links to be
> > > included in the repo?
> > 
> > I do not understand this question.
> 
> Let me rephrase quickly : From a checkout inside ~/puppet-modules/ when
> I run something like this :
> puppetdoc --mode rdoc --outputdir ./doc \
>   --modulepath modules --manifestdir /var/empty
> 
> I then get html documentation inside ./doc/ but all of the manifests
> files are referred to as /home/myuser/puppet-modules which would be
> quite ugly if included in the git repo or on a website as documentation.
Do you mean the file path of the parsed manifest mentioned when you
click on a class?
I''m afraid this is a bug nobody cared about. Can you file a redmine
ticket, please?
> I''ve just tested with 2.6.8 and I still get the same result. There
are
> more details, like the module''s main class showing up as
xinetd::xinetd
> instead of just xinetd or my definition''s parameters needing to be
> right after the "define" line (no empty line in between allowed)
or the
> documented #-- not working to stop further parsing...
About the xinetd::xinetd it''s by design. The module is called xinetd
itself and we need a way to distinguish the "global" module space (ie
xinetd) from the class called xinetd which lives in this module. It
could well have been possible that you have a "manifests" (not module)
class called xinetd which would have collisionned with this one in the
UI. Thus I used xinetd::xinetd. 
I could have make it xinetd::main or something akin but that I''m sure
you wouldn''t have find it better. 

The #-- needs to be actually be written as ##-- until I fix this
offending bug. I don''t think we have a redmine entry for this, so if
you
feel brave enough go add one (and even better produce a patch to fix the
bug :))
> Are others using puppetdoc for their modules? Are there some good
> examples out there? The official documentation is useful but seems
> somewhat limited.
I think Alessandro is using puppetdoc for his own module, check Lab42''s
Example42 modules on github:
https://github.com/example42/puppet-modules

Patches are more than welcome (even documentation patches) :)
-- 
Brice Figureau
Follow the latest Puppet Community evolutions on www.planetpuppet.org!

-- 
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.