Hi, On 06/13/2012 10:57 AM, Jo Rhett wrote: > On Jun 13, 2012, at 1:50 AM, R.I.Pienaar wrote: >> I can think of a few, but really any case where a files mode out of the >> box from say RPM prevent some other service from functioning because it >> relies on this file. File mode change -> dependant service restart. >> >> Lots of daemons ship files like accessible only by $daemon:$daemon when >> what we need is $daemon:$otherdaemon or maybe $daemon:$group_of_daemons. >> You want to notice $otherdaemon that it can now read that file etc > > > Good point. I outright stole and p0wned your words here for > http://projects.puppetlabs.com/issues/14998
(I don't think that's what 'pwning' means ;-) This idea makes me somewhat unconfortable. I get the feeling that this change would be a lot more fundamental than one might think. To puppet, each and every resource has one (more or less complex) state, and puppet either accepts this state or sees need to change it. If changed, fire a notify to all subscribers. That's it. What you're suggesting is a differentiation that has never existed in this context (afaik). I'm not sure I feel good about opening this door - I can easily see it become a gateway for lots of unintended effects to trip users up. As for your original problem, I don't see a good way of safeguarding against this in puppet. Personally, I refrain from having puppet restart services unless they are quite "safe", i.e. unlikely to stop working for some reason. Usually I don't want to run the risk of having unattended restarts at more or less random times, so for critical services - my advice is to just do those by hand (or mcollective). Cheers, 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.
