On Jun 18, 2012, at 6:04 PM, Jo Rhett wrote: > 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.
No, it's not the easiest way to break your environment. but it is a direct line to future obfuscated breakage, red herrings, and new and exciting ways to waste lots of engineers' time trying to suss out what in the the last N changes broke $package. Not taking that into account will arguably lead one to making bad design choices. Aren't we supposed to be lazy and try to NOT shoot ourselves in the foot unexpectedly? >> 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? There's many ways of doing this… A case statement tied to a version number, or some other fact will get you this.. Aren't you pretty clearly stating that this old generation IS different than the next generation? How is puppet supposed to KNOW the difference between the two? I've yet to see a satisfactory implementation of 'do what I mean, not what I say'.. but then again, I think that's why we're driving the computers and not the other way around… oof. My laptop's out of battery… have to go plug it in…Hey… Wait a minute.. ________________________________ This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/legal/email_disclaimer/ for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. -- 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.
