On Jun 18, 2012, at 1:57 PM, Wolf Noble wrote: >> Well, a in the service of b -- but as a general point, I think that every >> notify/subscribe should be tune-able as to which things changing will cause >> the action to take place. > > Not to continue this thread longer than it needs to go, but wouldn't your > suggested paradigm permit you to bite yourself in the following scenario: > - change the ownership or mode of a file to the point that the required > application could no longer access the file > - exclude this change from notifying or triggering the application that the > permissions or ownership of its' config file have changed. > This change will go unnoticed until: > o Some random point in time in the future wherein the service "should" > restart according to the method you propose. > o Some part of the application needs to re-read it's configuration file > o The server reboots > Suddenly things don't work. You don't have a smoking gun for the culprit > change as that "clean" deployment happened [hours,days,weeks] ago with some > other "unrelated" change by some other team that this service was set to > ignore.
I do believe I can shoot myself in the foot a dozen different ways that puppet does allow me to do: * break the configuration in the change * fail to restart the service * break some other dependancy …etc The short version is this is nowhere close to the easiest way to bag the service or host. I can do it dozens of ways with puppet today. It's my job to write the policy well, and test it well, and test all its dependencies. Puppet can't save me from myself. What would be really nice is if I can, writing my policy carefully, achieve more granularity, more control. Saying that I shouldn't have finer-grained control because I could bag the service makes no sense, unless this was opening some new vector in which to do so. It isn't. > Just my $.02, but if a file's ownership shouldn't change, and it belongs to > a specific module, and there becomes a reason to change that ownership, > without impacting existing modules, does it make sense to create a different > module, and manage the dissimilar needs via that route? Same software, same management functions, same configs… just a different permissions change on new installations. Should I really duplicate the entire module, and manage all changes in both places? And forever try to manage which host should be in which generation? -- 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.
