Issue #5286 has been updated by John Bollinger.
Jo Rhett wrote: > The logic for this isn't that hard to figure out. An Exec with a schedule > should occur inside the schedule when running on its own. > An Exec that gets notified should run. > > It may be a safe argument that the Exec could be set to run at 2am, but I > don't think Puppet has a setaside for that option do they? If they did, we > could argue that this is desired behavior. But since puppet doesn't track > that, I think we could safely argue that what RIP expects here is the > natural, expected behavior. > > *OR* you could argue that notifies shouldn't go to Execs with schedules, and > another exec with 'notifyonly' would solve the problem. But whichever answer > is chosen should be documented. First off, I would like to observe that the difference in behavior between the scheduled File and Service resources is internally consistent. File resources do not have a refresh action, so 'notify'ing them is precisely equivalent to 'before'ing them. That File['/tmp/bar'] is not actually synchronized (on account of its schedule) does not violate the declared relationship. The behavior of the Exec, on the other hand, is related to issue 5876. It is declared without "refreshonly => true", therefore (I say) its command should be considered a synchronization action, not a refresh action. As such, the Exec should be like the File, and its command should not run. If it did have "refreshonly => true", however, then the expected behavior should instead be analogous to the Service's. Services have distinct, non-trivial synchronization and refresh actions. Puppet's observed behavior is to run the refresh action when the Service is notified, even though its schedule prevented it from being synchronized. That would be a direct violation of my expectation (4) about synchronization and refreshing (see Issue 5876 comments), hence I account it a bug. Without even considering whether schedules should apply directly to refreshes, then, the behavior I would expect and find reasonable is (all of): a) File['/tmp/foo'] is successfully synchronized. b) File['/tmp/bar'] is not synchronized (the schedule excludes it). c) Exec['test']'s command is not run (the schedule excludes it). d) Service['httpd'] is not restarted (the schedule excludes it being synchronized, which is a prerequisite). e) The agent throws an error at least for the Service, and maybe also for the File and Exec, on account of being unable to refresh those resources. In particular, I would not find it reasonable for a resource's assigned schedule to be subject to countermanding by a separate resource. It follows that it is perilous to rely on refreshing a resource that has an assigned schedule, but I think that's necessary to maintain logical consistency. It is somewhat safer if the signaler is on the same schedule, but even then the schedule's 'repeat' parameter can mess you up. As an alternative, I think it would be reasonable and not too inconsistent for trivial actions to be ignored for this purpose. That would mean that no error would be thrown for the Exec (or File), and that if the Exec were refreshonly then its command would run (but otherwise not). Mixing notification with schedules would still be perilous, but perhaps a little less so. John ---------------------------------------- Bug #5286: Resources with schedules attached doesnt behave consistantly when notified https://projects.puppetlabs.com/issues/5286#change-76110 Author: R.I. Pienaar Status: Needs Decision Priority: Normal Assignee: R.I. Pienaar Category: Target version: Affected Puppet version: 2.6.2 Keywords: Branch: I was trying to figure out if an exec that gets notified outside of its schedule will still be run and noticed some inconsistencies. Given this code: <pre> schedule { daily: period => daily, range => "02:00 - 04:00" } file{"/tmp/bar": content => "bar", schedule => "daily", } exec{"test": command => "/usr/bin/cowsay moo", logoutput => true, schedule => "daily"} service{"httpd": schedule => "daily"} file{"/tmp/foo": content => "moo", notify => [ File["/tmp/bar"], Exec["test"], Service["httpd"] ] } </pre> If /tmp/foo doesn't exist and its not 02:00 - 04:00 I would either expect nothing else to happen or the file, exec and service all realized: <pre> % rm /tmp/foo /tmp/bar; puppet test.pp notice: /Stage[main]//File[/tmp/foo]/ensure: defined content as '{md5}b7d192a44e0da16cd180ebe85efb7c8f' notice: /Stage[main]//Service[httpd]: Triggered 'refresh' from 1 events notice: /Stage[main]//Exec[test]/returns: _____ notice: /Stage[main]//Exec[test]/returns: < moo > notice: /Stage[main]//Exec[test]/returns: ----- notice: /Stage[main]//Exec[test]/returns: \ ^__^ notice: /Stage[main]//Exec[test]/returns: \ (oo)\_______ notice: /Stage[main]//Exec[test]/returns: (__)\ )\/\ notice: /Stage[main]//Exec[test]/returns: ||----w | notice: /Stage[main]//Exec[test]/returns: || || notice: /Stage[main]//Exec[test]: Triggered 'refresh' from 1 events </pre> The file /tmp/bar isn't being created - its outside of schedule - but the exec runs and service gets notified. If I now run it again without deleting the file /tmp/foo then as expected the exec doesn't get run. I don't know what the desired behavior here is, I hoped notifying resources outside of their schedule will result in exec's running etc but I think that isn't the most common desire, the documentation says: <pre> schedule { maint: range => “2 - 4”, period => daily, repeat => 1 } With this schedule, the first time that Puppet runs between 2 and 4 AM, all resources with this schedule will get applied, but they won’t get applied again between 2 and 4 because they will have already run once that day, and they won’t get applied outside that schedule because they will be outside the scheduled range. </pre> We should either clarify how this applies to notified resources and I guess there is also a question of how resources - like file in my example - that doesn't really do anything when notified should behave in this scenario. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
