hello,
----- "berber" <webersi...@gmail.com> wrote:
> Now consider a company running hundreds of production servers with
> puppet running continuously every hour and over the night random
> servers start to fail. By the time someone understands that puppet is
> to blame and stops it (one may think there is an attack), more
> servers may fail. At this point you may have 10,20,100 servers down and no
> puppet to fix them as the current version has a bug that randomly
> ("occasionally") kills files.
You could say the same about most parts of the software stack, edge cases are
very hard to find and define.
In the end though puppet has the flexibility to work in both modes and all you
have to do is find a balance that meets your needs, not everyone has the same
availability or real-time needs, many only use puppet during deploy time.
> Why would anyone want to put himself in this situation instead of
> running puppet on a need to deploy basis?
I run it full time but I have the ability to enable/disable or run subsets of
my architectures during at-risk periods, for some clients i disble puppet at
night and only run it when people are around for example.
http://www.devco.net/archives/2009/11/30/managing_puppetd_with_mcollective.php
> I was looking for "cached catalog" but could not find a reference to
> it in the documentation, can you point me there?
Search in http://reductivelabs.com/trac/puppet/wiki/ConfigurationReference for
usecacheonfailure
> > 1) Don't disable using the cached catalog in case of failure
I'm curious why you recommend using this as a feature to enhance reliability?
It does the opposite.
I'd argue against the usecacheonfailure=true as a setting:
It's true that it would use a cache of the old compiled catalog if there's a
mistake in the new catalog. BUT it will still fetch files sourced with
puppet:/// from the server, it will still apply new packages set with
ensure=>latest and so forth.
What it will not do is rebuild templates. So you could quite easily get in a
situation where perhaps you've updated a package but applying config from old
templates. Or you've updated one config file in a service but not another -
since it comes from a template leading to weird unpredictable sets of
circumstances made worse if you notify services etc.
--
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-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
