Puppet users - Sep 2011 - Organizational best practices / examples

Hi folks,

I was curious if anyone would be willing to share how they organize their
puppet implementation. Perhaps something similar to what you''ll find at
https://fedoraproject.org/wiki/Infrastructure/Puppet.

People should have this sort of stuff documented, appreciate anything anyone
would be willing to share.

// colyte

-- 
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 09/01/2011 04:32 AM, col yte wrote:
> Hi folks,
>
> I was curious if anyone would be willing to share how they organize
> their puppet implementation. Perhaps something similar to what
you''ll
> find at https://fedoraproject.org/wiki/Infrastructure/Puppet.
>
> People should have this sort of stuff documented, appreciate anything
> anyone would be willing to share.
Hello,

In our environment we''ve made a concious decision to maintain modules/ 
in as generic a fashion as possible.  Basically, the way it works is 
that before we commit to modules/ we ask, "would we be comfortable 
sharing this on Github?"  It''s a surprisingly good strategy. :)

I realise this is only a small element of what you''re asking for, but I
am also curious to know if anybody else out there has any sort of 
"simple rules" that can applied in order to preserve sanity.

-- 
Daniel Maher
« makin'' plans now to live on Mars ''cuz I got Earth on lock. »

-- 
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 Sep 1, 4:47 am, Daniel Maher <dma...@milestonelab.com>
wrote:
> On 09/01/2011 04:32 AM, col yte wrote:
>
> > Hi folks,
>
> > I was curious if anyone would be willing to share how they organize
> > their puppet implementation. Perhaps something similar to what
you''ll
> > find athttps://fedoraproject.org/wiki/Infrastructure/Puppet.
>
> > People should have this sort of stuff documented, appreciate anything
> > anyone would be willing to share.
>
> Hello,
>
> In our environment we''ve made a concious decision to maintain
modules/
> in as generic a fashion as possible.  Basically, the way it works is
> that before we commit to modules/ we ask, "would we be comfortable
> sharing this on Github?"  It''s a surprisingly good strategy.
:)
>
> I realise this is only a small element of what you''re asking for,
but I
> am also curious to know if anybody else out there has any sort of
> "simple rules" that can applied in order to preserve sanity.
>
> --
> Daniel Maher
> makin'' plans now to live on Mars ''cuz I got Earth on
lock.
A bit late to respond, but thought I''d offer what has worked for me.
I too have adopted the idea "would I be comfortable sharing this on
github" with most of my modules.  The other thing I try to do is make
each module its own git repo that''s a submodule for the entire puppet
module directory.  I''m still working on the best workflow for that
situation, but the benefit is it allows me to easily publish
individual modules.

Also one thing I''ve made use of is Mediawiki and the Semantic
Mediawiki extension to effectively document my modules.  It''s also
served well for documenting all my servers.

Here are two examples...

Standard Mediawiki usage (slightly out-of-date)
https://cllaprojectwiki.tamu.edu/wiki/Puppetmaster_Configuration

An example of how to use the Semantic extension to allow for a very
neat way to organize data...
https://cllaprojectwiki.tamu.edu/wiki/Puppet_Module_Overview

I''ve found the use of Semantic mediawiki to be extremely helpful.  For
my server documentation each server gets it''s own page and all the
properties per page can easily build reports or tables (like the above
link).  Same goes for Puppet modules.  You can have properties like
"node_parameters" or "requires_module" and build tables /
reports on
that information.

- Trey

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