Puppet users - Jul 2009 - Best Practices Rewrite - First Draft

Hi Puppeteers,

I spent some time tonight making a first pass at what I hope will
eventually be a good replacement for the current "Puppet Best
Practices" page on the wiki. I know this needs *tons of work, but I
hit a good pausing point and decided it was time to ask for feedback
and contributions. The idea here is to provide some overall guidelines
to help newcomers to Puppet establish good habits as well as get the
most out of Puppet, and especially to highlight some common mistakes
and how to avoid them.

Please take a look and flame away. I need feedback, both positive and
negative, as well as input as to what the Best Practices actually are
(Volcane, I''m looking at you!). I especially need to flesh out that
final section.

RST format: http://plathrop.tertiusfamily.net/puppet/best-practice-draft.rst
HTML rendering:
http://plathrop.tertiusfamily.net/puppet/best-practice-draft.html

When this is closer to complete, and when I have permissions to do so,
I''ll create a new page on the wiki for this.

--Paul

-- 
"My pants growl with the hunger of a thousand bubblebees. And it feels
like a Koala crapped a rainbow in my brain!" -MasterShakezula

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

Paul Lathrop wrote:
> Hi Puppeteers,
> 
> I spent some time tonight making a first pass at what I hope will
> eventually be a good replacement for the current "Puppet Best
> Practices" page on the wiki. I know this needs *tons of work, but I
> hit a good pausing point and decided it was time to ask for feedback
> and contributions. The idea here is to provide some overall guidelines
> to help newcomers to Puppet establish good habits as well as get the
> most out of Puppet, and especially to highlight some common mistakes
> and how to avoid them.
> 
> Please take a look and flame away. I need feedback, both positive and
> negative, as well as input as to what the Best Practices actually are
> (Volcane, I''m looking at you!). I especially need to flesh out
that
> final section.
Thanks for picking up that work. It''s good to see movement here!

There are some thing I''m missing:

* How to arrange modules, what constitutes a module?

There''s this quip "If you ever wonder whether X is running, X
should be
a module." Also, some thoughts about how using external modules works?

* Environments and the workflow surrounding them

There is already UsingMultipleEnvironments, which has all the technical 
stuff. Perhaps a few sentences about how to use the production, testing, 
and development environment.

* An overview of the recommended filesystem layout

What goes to /etc/puppet, where to put modules and modules in different 
environments.

* Using an external node classifier to split configuration 
(node+data+class list) and manifests (modules and manifests)

* Recommend to replace complete config files instead of "editing" it 
in-place.



Thank you again for your time and work!

Regards, DavidS

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

Paul Lathrop <paul@tertiusfamily.net> writes:
> Hi Puppeteers,
>
> I spent some time tonight making a first pass at what I hope will
> eventually be a good replacement for the current "Puppet Best
> Practices" page on the wiki.
Thanks!
> Please take a look and flame away. I need feedback, both positive and
> negative, as well as input as to what the Best Practices actually are
> (Volcane, I''m looking at you!). I especially need to flesh out
that
> final section.
I''m sure you know this but when you talk about version control be sure
to mention a syntax-checking pre-commit hook.  That has saved us
countless hours.  This page has hooks for SVN and Git:
http://reductivelabs.com/trac/puppet/wiki/PuppetVersionControl


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

Hi Paul,

Some comments about the doc.

"Use double-quotes around node names"  I would say using single quotes
is better since the Puppet language does not try to parse it for  
variables.  I have not done any tests in Puppet of single over double  
quotes but have seen other interpreted languages recommend single  
quote first over double for performance reasons.

At least for me I tend to make Puppet modules very atomic.  Meaning  
many smaller modules/classes than one large monolithic module.  ie you  
want to manage ssh.  Perhaps break it up into a client and server  
class, but one module.

For multi-platform support I''ve found the best way to support it is  
via case statements at the high level

class openssh {
     case $operatingsystem {
         centos, redhat: { include openssh::redhat }
         debian, ubuntu: { include openssh::debian }
         default: { fail("${title} is not defined for operating system  
${operatingsystem}.") }
     }
}

Any common steps can be included in the class or broken out into a  
openssh::base class

In some cases you not only want to install the application, but they  
are situations to remove it (in my case had a need to ensure the  
package is removed for security)  I use the naming convention
cups::disable  -  To install but disable service (primarily for  
dependancy with other packages)
cups::remove  - To make sure the package and service are not running

Inheritance is great for creating a generic module and creating a site  
module for your specific needs (In my case we have a generic proftpd  
but then have a site specific for custom DirectAdmin (a hosting  
control panel) configurations )

Teyo''s recommends two module folders, one dist and another site.  site
folder containing modules specific to your install.

-L

--
Larry Ludwig
Reductive Labs


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

Hi
> "Use double-quotes around node names"  I would say using single
quotes
> is better since the Puppet language does not try to parse it for
> variables.  I have not done any tests in Puppet of single over double
> quotes but have seen other interpreted languages recommend single
> quote first over double for performance reasons.
so do I, but maybe another flamewar? ;) But I never thought about the  
performance issue, might be a reasonable argument.
> At least for me I tend to make Puppet modules very atomic.  Meaning
> many smaller modules/classes than one large monolithic module.  ie you
> want to manage ssh.  Perhaps break it up into a client and server
> class, but one module.
+1
> For multi-platform support I''ve found the best way to support it
is
> via case statements at the high level
>
> class openssh {
>      case $operatingsystem {
>          centos, redhat: { include openssh::redhat }
>          debian, ubuntu: { include openssh::debian }
>          default: { fail("${title} is not defined for operating system
> ${operatingsystem}.") }
>      }
> }
>
> Any common steps can be included in the class or broken out into a
> openssh::base class
so do I! so +1
> In some cases you not only want to install the application, but they
> are situations to remove it (in my case had a need to ensure the
> package is removed for security)  I use the naming convention
> cups::disable  -  To install but disable service (primarily for
> dependancy with other packages)
> cups::remove  - To make sure the package and service are not running
+1
> Inheritance is great for creating a generic module and creating a site
> module for your specific needs (In my case we have a generic proftpd
> but then have a site specific for custom DirectAdmin (a hosting
> control panel) configurations )
+1
> Teyo''s recommends two module folders, one dist and another site. 
site
> folder containing modules specific to your install.
good idea! Currently I have all site specific stuff in one big module,  
but like that I might be able to organize it again in modules per each  
site specific module adaptions. Question: Is autoloading looking in  
both module directories? so if it''s not found in the module in one  
module directory it''s still looking in the other one? I assume so, but
as I haven''t used it yet I better ask... ;)

cheers pete

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

>
> good idea! Currently I have all site specific stuff in one big module,
> but like that I might be able to organize it again in modules per each
> site specific module adaptions. Question: Is autoloading looking in
> both module directories? so if it''s not found in the module in one
> module directory it''s still looking in the other one? I assume so,
but
> as I haven''t used it yet I better ask... ;)

modulepath option must be set in your puppet.conf file.

-L

--
Larry Ludwig






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

Mark Plaksin wrote:
> I''m sure you know this but when you talk about version control be
> sure to mention a syntax-checking pre-commit hook.  That has saved
> us countless hours.  This page has hooks for SVN and Git:
> http://reductivelabs.com/trac/puppet/wiki/PuppetVersionControl
Indeed, this helps a lot for catching the really obvious typos, thanks
Mark for helping to work out a good git hook.  One potential fix for
that is to check for deletions, like so:

--- puppet-update-hook~	2009-07-23 09:53:52.000000000 -0400
+++ puppet-update-hook	2009-07-23 09:58:11.000000000 -0400
@@ -15,6 +15,10 @@
 do
     # skip lines showing parent commit
     test -z "$new_sha1" && continue
+
+    # skip deletions
+    [ "$new_sha1" =
"0000000000000000000000000000000000000000" ] && continue
+
     # Only test .pp files
     if [[ $name =~ [.]pp$ ]]
     then

One other potential problem is if puppet is used to manage selinux
modules.  Compiled modules also have a .pp extension.  When adding or
updating these files they will pass the "if [[ $name =~ [.]pp$ ]]"
check.  This can be avoided by not version controlling the compiled
modules, but perhaps it might also be reasonable to add a quick bit to
the if test, something like this (untested):

    if [[ $name =~ [.]pp$ ]] && [ "$(file -b "$name"
2>/dev/null)" != ''data'' ]

The selinux .pp files will return data, while I can''t imaging any
puppet manifests being labeled as data. :)

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A lot of people I know believe in positive thinking, and so do I.  I
believe everything positively stinks.
    -- Lew Col

Hi
>> good idea! Currently I have all site specific stuff in one big module,
>> but like that I might be able to organize it again in modules per each
>> site specific module adaptions. Question: Is autoloading looking in
>> both module directories? so if it''s not found in the module in
one
>> module directory it''s still looking in the other one? I assume
so, but
>> as I haven''t used it yet I better ask... ;)
>
>
> modulepath option must be set in your puppet.conf file.
yeah, that for sure. But so I assume it looks for ssh::client in every  
ssh module it can find in the different modulepaths.

cheers pete

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

Todd Zullinger <tmz@pobox.com> writes:
> One potential fix for that is to check for deletions, like so:
Thanks for doing work for us :)  We noticed the need for this but
haven''t had a chance to fix it.  Your change works great.  I updated
the
Wiki.
> One other potential problem is if puppet is used to manage selinux
> modules.  Compiled modules also have a .pp extension.  When adding or
> updating these files they will pass the "if [[ $name =~ [.]pp$
]]"
> check.  This can be avoided by not version controlling the compiled
> modules, but perhaps it might also be reasonable to add a quick bit to
> the if test, something like this (untested):
>
>     if [[ $name =~ [.]pp$ ]] && [ "$(file -b "$name"
2>/dev/null)" != ''data'' ]
>
> The selinux .pp files will return data, while I can''t imaging any
> puppet manifests being labeled as data. :)
This sounds good to me but maybe it''s not safe to assume GNU file
(which
supports the -b) is installed on your puppetmaster?


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

----- "Paul Lathrop" <paul@tertiusfamily.net> wrote:
> Hi Puppeteers,
> 
> I spent some time tonight making a first pass at what I hope will
> eventually be a good replacement for the current "Puppet Best
> Practices" page on the wiki. I know this needs *tons of work, but I
> hit a good pausing point and decided it was time to ask for feedback
> and contributions. The idea here is to provide some overall
> guidelines
> to help newcomers to Puppet establish good habits as well as get the
> most out of Puppet, and especially to highlight some common mistakes
> and how to avoid them.
> 
> Please take a look and flame away. I need feedback, both positive and
> negative, as well as input as to what the Best Practices actually are
> (Volcane, I''m looking at you!). I especially need to flesh out
that
> final section.
I was hoping to redraft this myself when 0.25 came out, but looks like
you''ve beat me to it.  Sadly, time doesn''t allow me to follow
up as closely with the user list as I''d like, (my participation with
Puppet as been limited lately to the asynchronous storeconfigs work
we''ve contracted).

Here are some comments to consider:

* A lot of this does read more like an introduction to Puppet and Puppet
concepts, so some of this might need to be broken away elsewhere.
* While classes aren''t object-oriented, I think treating them as if
they are isn''t necessarily a bad thing either.  Ultimately, when you
inherit you are only given yourself permission to override the declared
resources, but I also find it to be a good idea to keep this kind of modeling to
properly represent what is happening.  Ergo, when one class is a derivative of
another, I find it better to inherit instead of include, even if I am not
overriding a declared resource, simply because modeling shouldn''t be a
function of what features you are using.
* While one shouldn''t overuse dependencies, I wouldn''t put
notify and subscribe in the same boat since they are functionally useful for
things besides trying to make Puppet do something in a particular order.  I
think the intent was just to relate the two parameters to before and require but
I would recommend removing it or relocating it so we don''t give the
impression that using notify or subscribe is a bad idea.
* Because of complexity of how and when classes are interpreted, aren''t
variables often a tricky thing to play with if you are planning to change their
values in later scopes?
* Lastly, perhaps this is still my OCD, but I''m still a fan of the
style guide.  Without it, I dont'' think our manifests would be as clean
and legible as they currently are.


-- 
Digant C Kasundra <digant@stanford.edu>
Technical Lead, ITS Unix Systems and Applications, Stanford University

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

> * Environments and the workflow surrounding them
> 
> There is already UsingMultipleEnvironments, which has all the
> technical 
> stuff. Perhaps a few sentences about how to use the production,
> testing, 
> and development environment.
I''d love to be able to update that down the line (probably later this
year when we move to 0.25 and start using the environment support).  We had some
very specific ideas in mind for our use of environments with Git which i think
may be particularly useful for those institutions such as ours where we have
formal change management processes and vetting required from multiple
stakeholders in different departments, making fullscale migration difficult. 
I''ll see if i can draft something up.

-- 
Digant C Kasundra <digant@stanford.edu>
Technical Lead, ITS Unix Systems and Applications, Stanford University

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

Digant C Kasundra wrote:
> * Because of complexity of how and when classes are interpreted,
> aren''t variables often a tricky thing to play with if you are
> planning to change their values in later scopes?
With the current tooling, I think the only real chance is to put all 
"choosing values for variables which will influence my manifests" 
functionality in an external nodes classifier which does proper, 
flexible and organisation-specific lookups.

HAving this, manifests and modules do have a greatly reduced need to 
"change values in later scopes".
> * Lastly, perhaps this is still my OCD, but I''m still a fan of the
> style guide.  Without it, I dont'' think our manifests would be as
> clean and legible as they currently are.
+1


Regards, DavidS

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

> > * Because of complexity of how and when classes are interpreted,
> > aren''t variables often a tricky thing to play with if you are
> > planning to change their values in later scopes?
> 
> With the current tooling, I think the only real chance is to put all 
> "choosing values for variables which will influence my manifests"
> functionality in an external nodes classifier which does proper, 
> flexible and organisation-specific lookups.
> 
> HAving this, manifests and modules do have a greatly reduced need to 
> "change values in later scopes".
> 
I agree.
> > * Lastly, perhaps this is still my OCD, but I''m still a fan
of the
> > style guide.  Without it, I dont'' think our manifests would
be as
> > clean and legible as they currently are.
> 
> +1
:)


-- 
Digant C Kasundra <digant@stanford.edu>
Technical Lead, ITS Unix Systems and Applications, Stanford University

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

Mark Plaksin wrote:
>> One potential fix for that is to check for deletions, like so:
>
> Thanks for doing work for us :)  We noticed the need for this but
> haven''t had a chance to fix it.  Your change works great.  I
updated the
> Wiki.
Cool.  Credit for that one goes to Ricky Zhou.  When we added this the
Fedora Infrastructure puppet repo, he was the first one lucky enough
to get bitten by it.  :)
>> One other potential problem is if puppet is used to manage selinux
>> modules.  Compiled modules also have a .pp extension.  When adding or
>> updating these files they will pass the "if [[ $name =~ [.]pp$
]]"
>> check.  This can be avoided by not version controlling the compiled
>> modules, but perhaps it might also be reasonable to add a quick bit to
>> the if test, something like this (untested):
>>
>>     if [[ $name =~ [.]pp$ ]] && [ "$(file -b
"$name" 2>/dev/null)" != ''data'' ]
>>
>> The selinux .pp files will return data, while I can''t imaging
any
>> puppet manifests being labeled as data. :)
>
> This sounds good to me but maybe it''s not safe to assume GNU file
(which
> supports the -b) is installed on your puppetmaster?
It might not be a safe assumption.  Having any file command might not
be safe to assume, really.  Worse, the test above wouldn''t work
because $name would not be available as a file so the command would
fail.  Here''s something a little more likely to work (I did test this
one):

diff --git a/puppet-update-hook b/puppet-update-hook
index 539f969..74acaa7 100644
--- a/puppet-update-hook
+++ b/puppet-update-hook
@@ -40,6 +40,9 @@ do
   if [[ $name =~ [.]pp$ ]]
   then
     git cat-file blob $new_sha1 > $tmp
+    # SELinux modules also have a .pp extension, try to skip them
+    ftype="$((file "$tmp" | awk -F'': ''
''{print $2}'') 2>/dev/null)"
+    [ "$ftype" = "data" ] && continue
     set -o pipefail
     $syntax_check $tmp 2>&1 | sed
''s|/tmp/git.update.......:\([0-9]*\)$|JOJOMOJO:\1|''> $log
     if [[ $? != 0 ]]

If file isn''t available, the hook might still try to syntax check a
non-puppet .pp file, but that''s no worse than things are currently.

In testing, there are a few other things I noticed.  When making an
initial push with this hook enabled, $2 is 000000, which causes git
diff-tree to yield an error.  Fixing this would require a bit of
fiddling.  I''m also wondering if there''s any good reason to
keep the
''echo diff-tree:; cat $tree'' code?  It looks like leftover
debugging
to me.

One other potential improvement I have is to use shorter commit id''s
when telling a user how to check the diff when a problem is found:

diff --git a/puppet-update-hook b/puppet-update-hook
index 74acaa7..38551ef 100644
--- a/puppet-update-hook
+++ b/puppet-update-hook
@@ -49,7 +49,7 @@ do
     then
       echo
       echo -e "$(cat $log | sed
''s|JOJOMOJO|''\\${RED}${name}\\${NOBOLD}''|'')"
>&2
-      echo -e "For more details run this: ${CYAN} git diff $old_sha1
$new_sha1 ${NOBOLD}" >&2
+      echo -e "For more details run this: ${CYAN} git diff ${old_sha1:0:7}
${new_sha1:0:7} ${NOBOLD}" >&2
       echo
       exit_status=1
     fi

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It is impossible to enjoy idling thoroughly unless one has plenty of
work to do.
    -- Jerome K. Jerome

Thanks for all the feedback everyone. I''ll be working on a second
draft and getting it up on the wiki soon!

--Paul

On Thu, Jul 23, 2009 at 1:06 AM, David Schmitt<david@dasz.at>
wrote:
>
> Paul Lathrop wrote:
>> Hi Puppeteers,
>>
>> I spent some time tonight making a first pass at what I hope will
>> eventually be a good replacement for the current "Puppet Best
>> Practices" page on the wiki. I know this needs *tons of work, but
I
>> hit a good pausing point and decided it was time to ask for feedback
>> and contributions. The idea here is to provide some overall guidelines
>> to help newcomers to Puppet establish good habits as well as get the
>> most out of Puppet, and especially to highlight some common mistakes
>> and how to avoid them.
>>
>> Please take a look and flame away. I need feedback, both positive and
>> negative, as well as input as to what the Best Practices actually are
>> (Volcane, I''m looking at you!). I especially need to flesh out
that
>> final section.
>
> Thanks for picking up that work. It''s good to see movement here!
>
> There are some thing I''m missing:
>
> * How to arrange modules, what constitutes a module?
>
> There''s this quip "If you ever wonder whether X is running, X
should be
> a module." Also, some thoughts about how using external modules works?
>
> * Environments and the workflow surrounding them
>
> There is already UsingMultipleEnvironments, which has all the technical
> stuff. Perhaps a few sentences about how to use the production, testing,
> and development environment.
>
> * An overview of the recommended filesystem layout
>
> What goes to /etc/puppet, where to put modules and modules in different
> environments.
>
> * Using an external node classifier to split configuration
> (node+data+class list) and manifests (modules and manifests)
>
> * Recommend to replace complete config files instead of "editing"
it
> in-place.
>
>
>
> Thank you again for your time and work!
>
> Regards, DavidS
>
> >
>


-- 
"My pants growl with the hunger of a thousand bubblebees. And it feels
like a Koala crapped a rainbow in my brain!" -MasterShakezula

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

Hi,

David Schmitt wrote:
> * Environments and the workflow surrounding them
> 
> There is already UsingMultipleEnvironments, which has all the technical 
> stuff. Perhaps a few sentences about how to use the production, testing, 
> and development environment.
I sketched a schema describing the use of multiple environments and git
submodules for Puppet development.

It''s available on the wiki both in both OpenOffice Draw format and PDF.

http://reductivelabs.com/trac/puppet/attachment/wiki/PuppetVersionControl/puppetmaster-git-submodules.odg

http://reductivelabs.com/trac/puppet/attachment/wiki/PuppetVersionControl/puppetmaster-git-submodules.pdf

I''ll be glad if it could be useful for the best practices. It currently
relies heavily on git features, but it''s probably doable to sketch
something similar with other versionning tools.

François

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

Francois Deppierraz wrote:
> Hi,
> 
> David Schmitt wrote:
> 
>> * Environments and the workflow surrounding them
>>
>> There is already UsingMultipleEnvironments, which has all the technical
>> stuff. Perhaps a few sentences about how to use the production,
testing,
>> and development environment.
> 
> I sketched a schema describing the use of multiple environments and git
> submodules for Puppet development.
> 
> It''s available on the wiki both in both OpenOffice Draw format and
PDF.
> 
>
http://reductivelabs.com/trac/puppet/attachment/wiki/PuppetVersionControl/puppetmaster-git-submodules.odg
> 
>
http://reductivelabs.com/trac/puppet/attachment/wiki/PuppetVersionControl/puppetmaster-git-submodules.pdf
> 
> I''ll be glad if it could be useful for the best practices. It
currently
> relies heavily on git features, but it''s probably doable to sketch
> something similar with other versionning tools.
The more I think about it, the more I come to believe that puppet 
manifests should not only be version controlled, but also have a real 
release and patch cycle. Using submodules would be a convenient way to 
specify a release when working with git.

Thanks for the nice graphics :)


Regards, DavidS

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

> I sketched a schema describing the use of multiple environments and
> git
> submodules for Puppet development.
> 
> It''s available on the wiki both in both OpenOffice Draw format and
> PDF.
> 
>
http://reductivelabs.com/trac/puppet/attachment/wiki/PuppetVersionControl/puppetmaster-git-submodules.odg
> 
>
http://reductivelabs.com/trac/puppet/attachment/wiki/PuppetVersionControl/puppetmaster-git-submodules.pdf
> 
> I''ll be glad if it could be useful for the best practices. It
> currently
> relies heavily on git features, but it''s probably doable to sketch
> something similar with other versionning tools.
I''m not a git expert and can''t tell from the diagram if the
puppetmaster in this configuration can serve out multiple environments at once? 
And if so, how does it do that?  Does it not rely on different paths per
environment?

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

Hi

so I took again a look a this rather old thread, as I tried to implement
things as I thought I have understood them.
>>> good idea! Currently I have all site specific stuff in one big
module,
>>> but like that I might be able to organize it again in modules per
each
>>> site specific module adaptions. Question: Is autoloading looking in
>>> both module directories? so if it''s not found in the
module in one
>>> module directory it''s still looking in the other one? I
assume so, but
>>> as I haven''t used it yet I better ask... ;)
>>
>> modulepath option must be set in your puppet.conf file.
> 
> yeah, that for sure. But so I assume it looks for ssh::client in every  
> ssh module it can find in the different modulepaths.
After this discussion I thought that modules can be scattered amongst
the various module paths. But this doesn''t seem to be the case. At
least
my experience shows that puppet simply respects the classes of a module
it founds in the first location, all the classes in a second location
get ignored.

So the best practices would be to have 2 module paths, one with the
public modules and one module path with the site-specific module -
extensions, prefixed with site? so something like:

modules/public/apache <- public apache module
modules/site/site-apache <- site specific implementations of apache

To throw up the question:

Wouldn''t it be nicer if puppet would collect a module''s
classes from all
module pathes? It would at least make my site specific module changes
look a bit nicer and I still wouldn''t have to mix these. However I see
all the problems coming up with this solution. I''m just curious what
other people think.

cheers pete

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

----- "Peter Meier" <peter.meier@immerda.ch> wrote:
> Hi
> 
> so I took again a look a this rather old thread, as I tried to
> implement
> things as I thought I have understood them.
> 
> >>> good idea! Currently I have all site specific stuff in one big
> module,
> >>> but like that I might be able to organize it again in modules
per
> each
> >>> site specific module adaptions. Question: Is autoloading
looking
> in
> >>> both module directories? so if it''s not found in the
module in
> one
> >>> module directory it''s still looking in the other one?
I assume so,
> but
> >>> as I haven''t used it yet I better ask... ;)
> >>
> >> modulepath option must be set in your puppet.conf file.
> > 
> > yeah, that for sure. But so I assume it looks for ssh::client in
> every  
> > ssh module it can find in the different modulepaths.
> 
> After this discussion I thought that modules can be scattered amongst
> the various module paths. But this doesn''t seem to be the case. At
> least
> my experience shows that puppet simply respects the classes of a
> module
> it founds in the first location, all the classes in a second location
> get ignored.
> 
> So the best practices would be to have 2 module paths, one with the
> public modules and one module path with the site-specific module -
> extensions, prefixed with site? so something like:
> 
> modules/public/apache <- public apache module
> modules/site/site-apache <- site specific implementations of apache
> 
> To throw up the question:
> 
> Wouldn''t it be nicer if puppet would collect a module''s
classes from
> all
> module pathes? It would at least make my site specific module changes
> look a bit nicer and I still wouldn''t have to mix these. However I
> see
> all the problems coming up with this solution. I''m just curious
what
> other people think.
> 

I think that would be terrible.  Having two different paths for the same
namespace is confusing and will easily lead to problems.

However, the example you give is correct: you can''t have the same
module name in two modulepaths and usually want to prefix the classnames to
avoid name collisions.

-- 
Digant C Kasundra <digant@stanford.edu>
Technical Lead, ITS Unix Systems and Applications, Stanford University

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

Hi guys,

As Peter points out, this thread is old. Sorry I dropped the ball, I
plan on integrating feedback and getting this updated this weekend.

--Paul

On Wed, Sep 16, 2009 at 6:40 AM, Peter Meier <peter.meier@immerda.ch>
wrote:
>
> Hi
>
> so I took again a look a this rather old thread, as I tried to implement
> things as I thought I have understood them.
>
>>>> good idea! Currently I have all site specific stuff in one big
module,
>>>> but like that I might be able to organize it again in modules
per each
>>>> site specific module adaptions. Question: Is autoloading
looking in
>>>> both module directories? so if it''s not found in the
module in one
>>>> module directory it''s still looking in the other one?
I assume so, but
>>>> as I haven''t used it yet I better ask... ;)
>>>
>>> modulepath option must be set in your puppet.conf file.
>>
>> yeah, that for sure. But so I assume it looks for ssh::client in every
>> ssh module it can find in the different modulepaths.
>
> After this discussion I thought that modules can be scattered amongst
> the various module paths. But this doesn''t seem to be the case. At
least
> my experience shows that puppet simply respects the classes of a module
> it founds in the first location, all the classes in a second location
> get ignored.
>
> So the best practices would be to have 2 module paths, one with the
> public modules and one module path with the site-specific module -
> extensions, prefixed with site? so something like:
>
> modules/public/apache <- public apache module
> modules/site/site-apache <- site specific implementations of apache
>
> To throw up the question:
>
> Wouldn''t it be nicer if puppet would collect a module''s
classes from all
> module pathes? It would at least make my site specific module changes
> look a bit nicer and I still wouldn''t have to mix these. However I
see
> all the problems coming up with this solution. I''m just curious
what
> other people think.
>
> cheers pete
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Hi
> I think that would be terrible.  Having two different paths for the
> same namespace is confusing and will easily lead to problems.
yeah I feel more this way as well.
> However, the example you give is correct: you can''t have the same
> module name in two modulepaths and usually want to prefix the
> classnames to avoid name collisions.
so for the Best Practises:

If we do multiple sources for a file (and I do that a lot, as it makes
puppet so flexible) what would you prefer?

in module foobar and the 0.25 way:

file{''/tmp/a'':
  source => [ "puppet:///files/foobar/${fqdn}/a",
              "puppet:///files/foobar/a",
              "puppet:///modules/foobar/${operatingsystem}/a",
              "puppet:///modules/foobar/a" ],
}

or

file{''/tmp/a'':
  source => [ "puppet:///modules/site-foobar/${fqdn}/a",
              "puppet:///modules/site-foobar/a",
              "puppet:///modules/foobar/${operatingsystem}/a",
              "puppet:///modules/foobar/a" ],
}

???

cheers pete

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

I would have assumed that you''d always want to qualify the module
names as the best practise.  Collisions in namespaces wreak havoc in
many other domains.  I''m thinking of Java class names being bound to
domain names as an approach that works elsewhere.

Am I being naive?

Best

Julian

2009/9/17 Peter Meier <peter.meier@immerda.ch>:
>
> Hi
>
>> I think that would be terrible.  Having two different paths for the
>> same namespace is confusing and will easily lead to problems.
>
> yeah I feel more this way as well.
>
>> However, the example you give is correct: you can''t have the
same
>> module name in two modulepaths and usually want to prefix the
>> classnames to avoid name collisions.
>
> so for the Best Practises:
>
> If we do multiple sources for a file (and I do that a lot, as it makes
> puppet so flexible) what would you prefer?
>
> in module foobar and the 0.25 way:
>
> file{''/tmp/a'':
>  source => [ "puppet:///files/foobar/${fqdn}/a",
>              "puppet:///files/foobar/a",
>              "puppet:///modules/foobar/${operatingsystem}/a",
>              "puppet:///modules/foobar/a" ],
> }
>
> or
>
> file{''/tmp/a'':
>  source => [ "puppet:///modules/site-foobar/${fqdn}/a",
>              "puppet:///modules/site-foobar/a",
>              "puppet:///modules/foobar/${operatingsystem}/a",
>              "puppet:///modules/foobar/a" ],
> }
>
> ???
>
> cheers pete
>
> >
>


-- 
Julian Simpson
Software Build and Deployment
http://www.build-doctor.com

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

Julian Simpson wrote:
> I would have assumed that you''d always want to qualify the module
> names as the best practise.  Collisions in namespaces wreak havoc in
> many other domains.  I''m thinking of Java class names being bound
to
> domain names as an approach that works elsewhere.
Like rpm/deb packages, modules have a well regulated namespace. Iff 
there were a clash, those modules would probably come from two different 
implementors and quite likely do have different enough requirements and 
overlapping contents that they don''t work together anyways.

That being said "apache" just is much easier to type than 
"at.co.black.puppet.apache".[1]

Regards, DavidS



[1] and also would ruin the pun ;-)

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

Hey everyone,

Well, I really was meaning to get this cleaned up and put on the wiki,
but the world seems to conspire against it. First couple of times I
sat down to do it, I got Nagios pages. The last time was the real
winner, though. Tuesday night I sat down to get feedback integrated
and post this to the wiki when my partner called to me from the back
room.

To make a long story short: on Wednesday morning my son, who was
originally due Dec. 31st, decided to make an early appearance. He''s in
the NICU, and doing great, but my attention is probably going to be
elsewhere for awhile.

If anyone feels up to grabbing this document and running with it,
please feel free.

Regards,
Paul Lathrop

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

Le dimanche 11 octobre 2009 à 12:58 -0700, Paul Lathrop a écrit
:
> Hey everyone,
> 
> Well, I really was meaning to get this cleaned up and put on the wiki,
> but the world seems to conspire against it. First couple of times I
> sat down to do it, I got Nagios pages. The last time was the real
> winner, though. Tuesday night I sat down to get feedback integrated
> and post this to the wiki when my partner called to me from the back
> room.
> 
> To make a long story short: on Wednesday morning my son, who was
> originally due Dec. 31st, decided to make an early appearance.
He''s in
> the NICU, and doing great, but my attention is probably going to be
> elsewhere for awhile.
Congrats !

I swear people who use Puppet are more fertile.  Congratulations, Paul!

Julian.

2009/10/12 Nicolas Szalay <nszalay@qualigaz.com>:
> Le dimanche 11 octobre 2009 à 12:58 -0700, Paul Lathrop a écrit :
>> Hey everyone,
>>
>> Well, I really was meaning to get this cleaned up and put on the wiki,
>> but the world seems to conspire against it. First couple of times I
>> sat down to do it, I got Nagios pages. The last time was the real
>> winner, though. Tuesday night I sat down to get feedback integrated
>> and post this to the wiki when my partner called to me from the back
>> room.
>>
>> To make a long story short: on Wednesday morning my son, who was
>> originally due Dec. 31st, decided to make an early appearance.
He''s in
>> the NICU, and doing great, but my attention is probably going to be
>> elsewhere for awhile.
>
> Congrats !
>


-- 
Julian Simpson
Software Build and Deployment
http://www.build-doctor.com

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

Julian Simpson a écrit :
> I swear people who use Puppet are more fertile.  Congratulations, Paul!
>
> Julian.
>   
this is just that they do not let chaos do the job even in biology, all 
is managed in a central repository secured by ssl certificates where the 
family keeps his good practice since years now leading to a greater 
chance of success. Of course i think Paul should have a look at children 
virtualisation because they tend to proliferate quickly as they come 
natively with ''i want a brother'' service installed and running
on port
3year... :)


regards,
Jean.




--~--~---------~--~----~------------~-------~--~----~
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, Oct 11, 2009 at 12:58 PM, Paul Lathrop <paul.lathrop@gmail.com>
wrote:
>
> Hey everyone,
>
> Well, I really was meaning to get this cleaned up and put on the wiki,
> but the world seems to conspire against it. First couple of times I
> sat down to do it, I got Nagios pages. The last time was the real
> winner, though. Tuesday night I sat down to get feedback integrated
> and post this to the wiki when my partner called to me from the back
> room.
>
> To make a long story short: on Wednesday morning my son, who was
> originally due Dec. 31st, decided to make an early appearance.
He''s in
> the NICU, and doing great, but my attention is probably going to be
> elsewhere for awhile.
Congratulations Paul! Really glad to hear he''s doing well.

Hope the same holds true for you and your partner as well.

>
> If anyone feels up to grabbing this document and running with it,
> please feel free.
>
> Regards,
> Paul Lathrop
>
> >
>


-- 
nigel

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

Julian Simpson writes:
 > I swear people who use Puppet are more fertile.  Congratulations, Paul!

Or at least using Puppet frees up time for side projects.

--~--~---------~--~----~------------~-------~--~----~
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 Mon, Oct 12, 2009 at 5:09 AM, Jean Spirat <jeanspirat@squirk.org>
wrote:
>
> Julian Simpson a écrit :
>> I swear people who use Puppet are more fertile.  Congratulations, Paul!
>>
>> Julian.
>>
> this is just that they do not let chaos do the job even in biology, all
> is managed in a central repository secured by ssl certificates where the
> family keeps his good practice since years now leading to a greater
> chance of success. Of course i think Paul should have a look at children
> virtualisation because they tend to proliferate quickly as they come
> natively with ''i want a brother'' service installed and
running on port
> 3year... :)
You guys crack me up. Thanks for all the good wishes!

--Paul

--~--~---------~--~----~------------~-------~--~----~
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/10/09 12:42, Julian Simpson wrote:
> 
> I swear people who use Puppet are more fertile.  Congratulations, Paul!
> 
There may be something in that - I have two sets of twins :)

Congrats Paul!

R.


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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Lathrop wrote:
> You guys crack me up. Thanks for all the good wishes!
> 
> --Paul
Congrats +1!

node offspring inherits plathrop {
    include littlebundleofjoy
    include nosleep
    include puppet
}

Cheers

James Turnbull

- --
Author of:
* Pro Linux Systems Administration (http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet (http://tinyurl.com/pupbook)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEcBAEBAgAGBQJK05+OAAoJECFa/lDkFHAyS6MIALBdQoUFnLhQ7zoUwg/4mDK4
4pYRkeSGDWcg8S4l7SqQyI4on6XLVCXtRCqYQGG7pqF2tHuMt4oVed91TH+iwqJ1
Dkx626bmxpVGJpSNN3xOgMPDGfnpkbImOIW/EPGhBTEZELCsggYKL8N1JllZqHcF
lmS40/9WB7x/Dx3weJseiE3O2RkknyQrWFCb3QWiVF/Wp6g8HYT27w8+VCetF8UR
3lJYLQIe2A01IBckfLfyUD4T46WqNMFjchOlrac5yQVP8UE5XAZhGfD2Krvlt3zg
GMZbCLg14NB9J3IDg5aJZ4rGUAuqJzV9r3kH8Phi0JKTzVvnqHaH5iRiu/hmnQI=YPt2
-----END PGP SIGNATURE-----

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

Hi,
> If anyone feels up to grabbing this document and running with it,
> please feel free.
Not sure if I accidentally half replied to this already....

I''d be very happy to pick this up.  I''m just starting a new
project -
bring some best practices to a somewhat chaotic and messy large
government Drupal infrastructure (and associated services) and am also
doing some puppet training, so gathering together collected wisdom,
adding my own experiences from 3 years of running puppet, and
maintaining the document seems like an ideal fit.

Is everyone ok with this?

S.
-- 
Stephen Nelson-Smith
Technical Director
Atalanta Systems Ltd
www.atalanta-systems.com

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

No objections here.  I seem to recall that there had a been a
discussion at PuppetCamp about perhaps moving to a pattens collection
instead of set of best practices - not sure if anyone has bandwidth to
to work on this but it might help to keep it in mind.

Dan North wrote an article on this.[1]

http://www.infoq.com/articles/better-best-practices

Ironically I have loads of best practices articles on my blog. D''oh.

J.

2009/10/18 Stephen Nelson-Smith
<sanelson@gmail.com>:
>
> Hi,
>
>> If anyone feels up to grabbing this document and running with it,
>> please feel free.
>
> Not sure if I accidentally half replied to this already....
>
> I''d be very happy to pick this up.  I''m just starting a
new project -
> bring some best practices to a somewhat chaotic and messy large
> government Drupal infrastructure (and associated services) and am also
> doing some puppet training, so gathering together collected wisdom,
> adding my own experiences from 3 years of running puppet, and
> maintaining the document seems like an ideal fit.
>
> Is everyone ok with this?
>
> S.
> --
> Stephen Nelson-Smith
> Technical Director
> Atalanta Systems Ltd
> www.atalanta-systems.com
>
> >
>


-- 
Julian Simpson
Software Build and Deployment
http://www.build-doctor.com

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

''lo,

----- "Julian Simpson" <simpsonjulian@gmail.com> wrote:
> No objections here.  I seem to recall that there had a been a
> discussion at PuppetCamp about perhaps moving to a pattens collection
> instead of set of best practices - not sure if anyone has bandwidth
> to to work on this but it might help to keep it in mind.
Pattern collections are much better, I''d rather have articles exploring
features that people can learn each feature and then apply to their environment
than a best practice since those are almost always full of assumptions about
local conditions, patterns are flexible and can be molded to your needs..

-- 
R.I.Pienaar

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

R.I.Pienaar wrote:
> Pattern collections are much better, I''d rather have articles
> exploring features that people can learn each feature and then
> apply to their environment than a best practice since those are
> almost always full of assumptions about local conditions,
> patterns are flexible and can be molded to your needs..
> 
What Arri said.  I''d like to see logical, interlinked set of
patterns that can be built into a logical whole rather than a
single, potentially unwieldy document.

Regards

James Turnbull

- --
Author of:
* Pro Linux Systems Administration (http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet (http://tinyurl.com/pupbook)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEVAwUBStxEzCFa/lDkFHAyAQJymgf+KaNlFgd5Cn3hpPVPLhMU1StC+EvVcaUi
ChvDFrJp+dOB//ZoWUdf5W5BEDKNHVd1SfLZGdaZuv8fqR4dgG2u7B8UVcIKx/8t
Te0ocC7KxAxd1IhcYDfu20rcsEkN//WEiJFMoHSBq8fP0ZpzZl8yyCQQFIvtfl/c
AbCtAr3K42QH7zUxDqv/7aT/MSK1gqmC7Sl+892vdU/g7mEcfYQsgtXEsyRBHR8P
2040gJGlFa6YsAPySaMLUy3zpbK6pVubtn1FH2Jz+wkJZTyU1pvuBOzzV12foSfE
s3MQWh85qo2otKGnSBetNUaCOcbah/Xuedfr5LcRmFLHeu5x1R+RdA==11hx
-----END PGP SIGNATURE-----

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

hello,

----- "James Turnbull" <james@lovedthanlost.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> R.I.Pienaar wrote:
> 
> > Pattern collections are much better, I''d rather have articles
> > exploring features that people can learn each feature and then
> > apply to their environment than a best practice since those are
> > almost always full of assumptions about local conditions,
> > patterns are flexible and can be molded to your needs..
> > 
> 
> What Arri said.  I''d like to see logical, interlinked set of
> patterns that can be built into a logical whole rather than a
> single, potentially unwieldy document.
Sorry if you consider this just link spam, but read this url that covers just
this:

http://blogs.usenix.org/2009/10/16/tom-limoncellis-lisa-2009-training-design-patterns-for-system-administrators/

-- 
R.I.Pienaar

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

> If anyone feels up to grabbing this document and running with it,
> please feel free.
As the original author, I suppose I should take over.  Can you send me what you
had?

-- 
Digant C Kasundra <digant@stanford.edu>
Technical Lead, ITS Unix Systems and Applications, Stanford University

--~--~---------~--~----~------------~-------~--~----~
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 Fri, Oct 23, 2009 at 2:22 PM, Digant C Kasundra <digant@stanford.edu>
wrote:
>
>
>> If anyone feels up to grabbing this document and running with it,
>> please feel free.
>
> As the original author, I suppose I should take over.  Can you send me what
you had?
It''s available at the links I originally posted.

--Paul

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