On Wednesday, September 17, 2014 12:12:31 PM UTC-5, Andy Parker wrote: > > Adrien has put together a change to address PUP-1106 (failed dependencies > are not honored on refresh), however this is a really thorny issue and I'd > like to get some more eyes on it before committing to the change. > > I think the original bug in redmine has the most history ( > http://projects.puppetlabs.com/issues/5876) and unfortunately it doesn't > look like there was a clear decision about what the correct behavior is. I > think John's description of the semantics are pretty good, but I find it a > little hard to unravel it into what needs to change. > > Adrien's solution is to make it so that a resource *does not process > refresh events* when it is being skipped. Skipping can happen because of > failed dependencies or because the resource isn't scheduled. I'm going to > keep looking over it and will try it out some, but I think others should > kick these tires a bit as well. > >
Referring back to my comments on Redmine 5876, it sounds like that corresponds to ensuring that this expectation holds: > *(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. * I hadn't considered reasons for skipping synchronization other than failure of dependencies, but I absolutely agree that resources skipped for any reason should not refresh. But what about resources that themselves fail? Such resources also should not refresh. Does that already work, and/or is it addressed by Adrien's patch? Further question: an Exec that is considered in sync because of its 'creates', 'onlyif', and/or 'unless' parameter should not also be considered skipped. Is it necessary or appropriate for such a resource to avoid refreshing, too? Moreover, is it necessary or appropriate for the provider to evaluate those parameters (again) at refresh time? Additionally, there are some other behaviors around signaling and syncing that are discussed in the commentary on Redmine 5876, but that go a bit beyond the reported buggy behavior. These don't necessarily have to be addressed to close the issue, but if the commentary seems valuable then I hope it can be put somewhere less likely to be lost upon closure of the issue. In particular, I would really like to see this implemented: > *(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.* Perhaps Execs could retain a possibility to run twice (as they will do now if they receive a signal and are not refreshonly), though I have never come across an example where that behavior was invoked intentionally. If this is indeed implemented, then I think it would provide direction on the question I raised above about the 'creates', 'onlyif', and 'unless' parameters: that they should be processed once, to control the (at most one) execution of the Exec's command. There is also the question of the appropriate effect of a resource successfully syncing but failing to refresh. Should that cause dependent resources to be skipped? If not, then should it maybe cause refreshes of dependent resources to be skipped (supposing they receive a signal from some other resource)? -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/82db570f-9cd0-492b-b3f2-084f14032430%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
