Jo, this thread is starting to confuse me, I am no longer sure what you're suggesting, precisely.
a) Make it possible to nullify notifications under certain circumstances. b) Make it possible to ignore file owner/mode for files that exist already. While (b) is rather tasteless to me (as is the whole "replace" parameter), it is certainly well in line of what's possible today, so I wouldn't object too much. (a) is a nightmare I hope you're not invested in. > I find this whole discussion very interesting, in that it shows just how > small of a team most puppet sites are. I can't fathom modifying a > template to push out a change, and being able to prevent that puppet > client from picking up the change before the next maintenance window. > It's just not possible in any reasonably sized site. > > I'm thinking of sites where you edit a policy and two seconds later > someone on a different team "kicks" the host for an entirely different > reason. And perhaps they should have used a tag to limit what they > kicked, but perhaps they forgot. Or perhaps their module depends on > yours so they so added your module as a tag. This statement in itself is interesting as well. I believe that most sites, large or small, don't face this particular problem at all, because most of its incarnations are handled by manifest code control. If a change goes to production, it better work, otherwise whoever pushed to production has to answer for the breakage. Of course, there may be sites that (for any number of reasons) cannot adopt such a model(?) On 06/15/2012 08:41 PM, Jo Rhett wrote: > Not all things can be restarted after they are operating. Some things > need to be initialized restarted, and then never restarted again unless > there is a good reason (like a configuration change). Saying "oh just > restart it anyway makes no sense". Why have refreshonly => true if that > was so? I don't mean to imply that we shouldn't have this whole discussion, but the above example is hardly an argument in my humble optinion. If you have a service that should under no circumstances be restarted unattended, then for crying out loud, do not make it consume resource notifications from puppet. That's begging for trouble. Yeah, sorry for derailing this again ;-) Best, Felix -- 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.
