Best Practices Rewrite - First Draft
Paul Lathrop
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
David Schmitt
> 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
Mark Plaksin
> 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
Larry Ludwig
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
Peter Meier
> "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
Larry Ludwig
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... ;)
-L
Todd Zullinger
> 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
Peter Meier
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
Mark Plaksin
> 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?
Digant C Kasundra
> 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 <dig...@stanford.edu>
Technical Lead, ITS Unix Systems and Applications, Stanford University
Digant C Kasundra
>
> 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.
David Schmitt
> * 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
Digant C Kasundra
> > 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
:)
Todd Zullinger
>> 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
Paul Lathrop
draft and getting it up on the wiki soon!
--Paul
Francois Deppierraz
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.
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
David Schmitt
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
Digant C Kasundra
> 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?
Peter Meier
so I took again a look a this rather old thread, as I tried to implement
things as I thought I have understood them.
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
Digant C Kasundra
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.
Paul Lathrop
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
Peter Meier
> 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
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...@immerda.ch>:
Julian Simpson
Software Build and Deployment
http://www.build-doctor.com
David Schmitt
> 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 ;-)
Paul Lathrop
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
Nicolas Szalay
> 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
Julian.
2009/10/12 Nicolas Szalay <nsz...@qualigaz.com>:
--
Jean Spirat
> I swear people who use Puppet are more fertile. Congratulations, Paul!
>
> Julian.
>
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.
Nigel Kersten
>
> 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.
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
Steven VanDevender
> I swear people who use Puppet are more fertile. Congratulations, Paul!
Or at least using Puppet frees up time for side projects.
Paul Lathrop
You guys crack me up. Thanks for all the good wishes!
--Paul
Robin Bowes
>
> 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.
James Turnbull
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-----
Stephen Nelson-Smith
> 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
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 <sane...@gmail.com>:
R.I.Pienaar
----- "Julian Simpson" <simpso...@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
James Turnbull
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-----
R.I.Pienaar
----- "James Turnbull" <ja...@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:
--
R.I.Pienaar
Digant C Kasundra
> 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
----- "James Turnbull" <ja...@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.
>
I suppose that's true. Though I have to say some of the patterns that developed in the PuppetCommon modules seemed bad, to me. I guess the issue really becomes when patterns are developed by people first exploring Puppet as opposed to people that have done it a while. But certainly, I think institutions tend to develop their own patterns. Stanford was glad to share what our collective wisdom was with the Best Practices and Style Guide but I think it might be time for us to pull our work back in-house so can we preserve these documents since they are still very much part of what our team uses.
Digant C Kasundra
----- "R.I.Pienaar" <r...@devco.net> wrote:
> 'lo,
>
> ----- "Julian Simpson" <simpso...@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..
That's very true. Different local needs and different levels of complexity and business requirements will definitely drive how things should be done. For instance, if you just want to use puppet to make sure a certain package is installed on all servers, you may not need the complexity of larger instances. We have a practice here (partially represented by the out of date best practices) that works well for a large institution with large amount of classes and large difference and ties to external entities like a CMDB. So well defined patterns can be good, but how to write them and more importantly, how to present them in a common area can be difficult, especially where there are multiple solutions to a given problem. Ideas?
Paul Lathrop
>
>
>> 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