… Now that I'm excessively caffeinated (I'm not actually sure if that's better,
or worse, than my previous state, but)…
On Jun 18, 2012, at 12:47 PM, Jo Rhett wrote:
> On Jun 18, 2012, at 12:55 AM, Felix Frank wrote:
>> 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.
>
> 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.
That really seems, to me at least, like a huge bag of pain to drag around
waiting to pull out simply because it's tuesday.
… I never could get the hang of tuesdays.
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?
That would at least let you know you're attempting to utilize two incompatible
resources before doing so
________________________________
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.
