Re: [Puppet Users] can we avoid notify/subscribe firing on a mode change?
Wolf Noble <wnoble <at> datapipe.com>
2012-06-18 23:41:34 GMT
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
>> - 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
> 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 <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.