On Jun 18, 2012, at 2:08 AM, David Schmitt wrote: > I say "running puppet *hot* on a system *when* restarting a service might > create a booboo is a bad idea." Emphasis on *hot* and *when*. For both > emphasises, there are solutions (noop, cron, schedules, mcollective, dssh). > Using a different CM is not likely to solve that unless you're willing to go > the build-freeze-scrap route.
I'm not certain I understand your definition of "hot". Is this normal puppet runs, puppet kick, etc. It's also not clear to me why you think it's bad. I hear your assertation, but I don't see any explanation of why you feel it is bad. For perspective, we routinely restart services while puppet is running "hot" (if I understood your definition there) and I'm not aware of any reason this is bad. Please educate me. > The core of this runs into organizational realms like "Change Management", > which are not in scope for the puppet master/agent. *boggle* Um, so your configuration management system is not part of your change management implementation? That's what you just said, and it makes no sense. > At the clients I work for, Rule #1 is "do not push into production." Even > some of the outward-facing "test" systems have sensitive times when clients > are testing. Developing changes and actually applying them are two VERY > separate activities. You might want to look into git-flow to dis-entangle > development, teams, and integration. You are either saying some incredibly obvious -- like not hacking on production schemas without testing -- or something that I'm not following. For this thread, none of these things appear to be topical. I'm not talking about how to manage changes to the production puppet policies. I'm talking about when someday a decision is made that new installations will have different rights, and after that new configuration is developed, tested and confirmed -- we should have the option of not changing the mode for existing installations. Right now, testing and development of that change let us to the conclusion that we had to remove the file from puppet entirely. Which means that it has to be managed by a different mechanism, which means a completely different configuration management system which can incorporate that idea. This is the meat of the problem: if this is a problem puppet shouldn't be used to handle, are you encouraging cfengine to be installed side by side with it? cfengine can handle this just fine. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
