On Thursday, June 14, 2012 2:22:44 AM UTC-5, Felix.Frank wrote: > > This idea makes me somewhat unconfortable. I get the feeling that this > change would be a lot more fundamental than one might think. >
I agree. > 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. > Special cases are *always* problematic. They are prone to bugginess, they make systems harder to understand, and they tend to trip up the unwary. With respect to the last, I do think that the current behavior is less likely to surprise users than the proposed one. Right now, you only have to know one rule about event firing: if any managed property is changed by Puppet, then an event is fired. Adding exceptions would make it easier to surprise users. Consider also how the proposed change might affect resources that subscribe to the File in question instead of being notified by it. It is not evident in *their* declarations how the target resource is configured. Would they still receive all the events they ever did (so that there is an inconsistency between the conditions triggering notifications and those triggering subscriptions) or would events be filtered for forms (so that subscribers can't tell what conditions will trigger events without scrutinizing the target resource, wherever it might be declared)? If finer grained event-handling behavior is desired, then it should be implemented as a general-purpose facility instead of as a one-off special case. For instance, it is conceivable that a future version of Puppet would allow for some kind of filter to be installed on notification and subscription relationships, to control which events are passed through based on which resource properties changed. I don't imagine that could happen before v3.1, however, if then. As for your original problem, I don't see a good way of safeguarding > against this in puppet. > I concur, and I do not favor implementing resource-specific special rules to provide such a safeguard. If it's essential to your operation, however, then you (Jo) have the source, so you can implement the behavior change you want for your own site. If you are prepared to contribute a patch to Puppetlabs then that would even make it more likely that the change would be accepted into the core (over Felix's objections and mine). John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/4itkAcJeJgMJ. 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.
