Issue #5876 has been updated by John Bollinger.
This issue seems to be complicated by the overlay of signaling / refreshing on top of conventional resource synchronization. Tags and schedules are just cream on top. Suppose, then, we look first at conventional syncronization. It seems reasonable and expected that (1) no attempt should be made to synchronize a resource if any of its direct or transitive dependencies fail to synchronize. Furthermore, (1a) if no attempt is made to sync a resource, then it is not synchronized, even if it has an otherwise trivial synchronization action (e.g. an Exec with refreshony => true). Since we're ignoring signaling for the moment, the dependencies in question are expressed only via 'require', 'before', and the non-signaling chain operators. I think this much works reliably. It also seems reasonable and expected that (2) a resource that is not synchronized should not emit signals, whether it failed itself, a dependency failed, or it was excluded based on tags or schedules. I think this also works. As we move a bit more into signaling, I think it is reasonable and expected that (3) if a resource is scheduled to be refreshed, then the refresh happens immediately following its _successful_ synchronization It follows, however, that (4) a resource that is not synchronized cannot be refreshed, regardless of what resource notifies it or to what other resource it may be subscribed. That stands to reason, but it seems not to be consistent with Puppet's current behavior, at least under some circumstances. That's the subject of this issue. Now we come to a potential point of contention: should it be possible for resource A to be synchronized if it subscribes to or is notified by failed resource B, but has no non-signaling relationship with B? The current documentation suggests not, inasmuch as it describes subscribe and notify as augmented require and before, respectively. I'm fine with that, but those constraints *could* be loosened to demand only an attempt at synchronization. That is, suppose Service['A'] subscribes to File['B'], but there are no other relationships between them. Then certainly the agent must try to synchronize File['B'] before Service['A'], but if File['B'] fails then the agent could attempt to sync Service['A'] anyway (though it would not receive a signal from File['B']). In that case, the currently-documented behavior could still be achieved by naming File['B'] in both kinds of relationships (e.g. A could both require => File['B'] and subscribe => File['B']). That would allow for gentler failure behavior in some cases, without precluding more stringent behavior where that is desired. There are therefore two possible rules here: (5') No attempt is made to synchronize a resource if it has a signaling dependency on a resource that fails, or (5") When one resource has a signaling dependency on another, any attempt to sync the dependency will be performed before any attempt to sync the dependent resource, but the latter attempt is not conditional on the success of the former. Execs are a bit of a special case, though they might serve as a model for certain custom resources or perhaps future resource types. For them (6) Execs should not be construed as having the same synchronization and refresh actions. Instead, they should be construed as having only one or the other. Thus, when an Exec has refreshonly => true that should mean its command is a refresh action (and the sync action is equivalent to /bin/true), whereas when it has refreshonly => false, its command is the sync action. That will produce the same behavior as Exec current exhibits in the vast majority of cases -- I think in all the cases that aren't considered buggy. There remains the question of what to do with dependencies on resources that sync successfully but fail to refresh. This is a second potential point of contention, but I suggest that (7) When resource A has only a non-signaling dependency on resource B, then failure of resource B to refresh does not prevent resource A from being synchronized or refreshed. The alternative, of course, is (7') When resource A has any type of dependency on resource B, and resource B fails to refresh, then no attempt is made to sync resource A. (There's no need to distinguish different types of dependencies in this case.) If (7) is adopted, then that leaves the question of what to do when A has a signaling dependency on B, and B fails to refresh. I suggest that the rule should be the same as (7), but it would be possible to refuse to sync A in that case. Wow, sorry for being long-winded (even for me). I hope this at least gets some meaningful discussion going on what the desired behavior is. ---------------------------------------- Bug #5876: Require and Subscribe on the same refreshonly exec doesnt work https://projects.puppetlabs.com/issues/5876#change-55186 Author: R.I. Pienaar Status: Needs More Information Priority: Normal Assignee: Nick Lewis Category: exec Target version: 2.7.x Affected Puppet version: 0.25.4 Keywords: Branch: Given this manifest: <pre> exec{"moo": command => "/usr/bin/cowsay 'fail :('", refreshonly => true, logoutput => true, require => Exec["false"], subscribe => [ File["/tmp/1"], File["/tmp/2"], File["/tmp/3"] ] } file{"/tmp/1": content => 1} file{"/tmp/2": content => 2} file{"/tmp/3": content => 3} exec{"false": command => "/bin/false"} </pre> The Exec[moo] shouldn't run it requires Exec[false] which will always fail, but it gets notified by the file resources via its subscribes and then runs anyway regardless of the state of the required resources. In version 2.6.5 this might be related to #5670 but I am filing a new bug since I think its not as this bug is also present in 0.25.x while the one in #5670 is 2.6.x only <pre> notice: //File[/tmp/1]/content: defined content as 'unknown checksum' notice: //File[/tmp/3]/content: defined content as 'unknown checksum' err: //Exec[false]/returns: change from notrun to 0 failed: /bin/false returned 1 instead of one of [0] at /home/rip/test.pp:12 notice: //File[/tmp/2]/content: defined content as 'unknown checksum' notice: //Exec[moo]: Dependency exec[/bin/false] has 1 failures warning: //Exec[moo]: Skipping because of failed dependencies notice: //Exec[moo]: Triggering 'refresh' from 3 dependencies notice: //Exec[moo]/returns: _________ notice: //Exec[moo]/returns: < fail :( > notice: //Exec[moo]/returns: --------- notice: //Exec[moo]/returns: \ ^__^ notice: //Exec[moo]/returns: \ (oo)\_______ notice: //Exec[moo]/returns: (__)\ )\/\ notice: //Exec[moo]/returns: ||----w | notice: //Exec[moo]/returns: || || </pre> -- 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.
