On Thu, Jun 14, 2012 at 11:20 AM, jcbollinger <john.bollin...@stjude.org>wrote: > > > 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.
Like most other posters so far I think that this would be such a fundamental change that it should come in a major version if anything. I wouldn't be opposed to the idea of being able to filter on parameters when doing a subscribe/notify, maybe a filter meta-parameter along the line of filter => ['source', 'owner' ], but like most people I feel this adds a lot of complexity for very little gain. I would prefer to simply schedule the puppet run that changes the mode and causes a service restart to occur out of hours and take the restart downtime. I feel it keeps things simple to retain the existing concept of notify. Thanks, -- 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.
