There may be, but when we want to upgrade an application and minimize downtime, a well-defined window of a checkin period is not sufficient. For example, given 10 machines, we need to upgrade 5, validate them, then upgrade the remaining 5. The 5 being upgraded will get pulled out of the load balancer during the puppet run. If the upgrade is deemed a failure, the old version must be reinstated on those 5 machines. This is all possible with puppet, and it feels like the master/agent relationship is an impediment.
-- Brian Lalor bla...@bravo5.org On Feb 13, 2013, at 4:09 PM, jcbollinger <john.bollin...@stjude.org> wrote: > I urge you to consider whether and to what extent you really need to control > when updated configuration is applied. Generally speaking, there are a lot > of circumstances in which it is quite sufficient to have a predictable window > in which you can rely on updates being applied, at least in terms of > functionality and level of service. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
