On Wednesday, March 16, 2016 at 12:06:08 PM UTC-5, Hunter Haugen wrote: > > > On Thursday, February 25, 2016 at 7:45:46 PM UTC-6, Trevor Vaughan wrote: >>> >>> Sorry about that. >>> >>> What I mean is this: >>> >>> A -> [] -> B is not equivalent to A -> B since failures in A will not >>> affect B. >>> >>> However, it would be equivalent to [A,B] which I am reading as A before >>> B but not in an actual resource relationship. >>> >> >> > Just to be a little more clear, when declaring resources I never use a > KNOWN empty-in-all-cases array in resource chains, so using "[]" is a leaky > analogy. >
I think everyone participating in the discussion understands that, but the variation in possible behaviors happens only when the expression in the middle of the chain happens to evaluate to zero resources, as "[]" trivially does. Please do not suggest that Puppet might exhibit different behavior when that expression can be evaluated statically than when it can be evaluated only via a full catalog build. > Instead one example is: > > Thing[a] -> Thing <| name == $::something::i::want |> -> Thing[b] > > Some people assume that the Thing[$::something::i::want] is declared and > if not then that is an error state. > > Some people assume that the Thing[$::something::i::want] may be declared, > but if not then that's fine. > > I hadn't considered that anyone might assume that it would be an error for the collector to collect zero resources under those circumstances, but I guess that's plausible. I thought we had taken as given that collecting zero resources was ok, though, and that we were talking about what should be the meaning of the overall chain when one of the middle expressions evaluates to zero resources., > But for all cases Thing[a] -> Thing[b] at most is desired, or at least is > possible. The only case in which disjointed dependencies are logically > different is when failures in Thing[a] do not skip the evaluation of > Thing[b] if and only if Thing[$::something::i::want] is undefined. > I'm not sure I follow you there. Under all circumstances the three element chain (currently) has exactly the same semantics as two two-element chains with respect to resource relationships, which are what determine at a low level how the resources are ordered and which are applied in the event that some fail. Are you saying that you want there to be a difference, as Trevor seemed to say? > Does that occur in the real world? Not afaik. > That was indeed my conclusion too, though. If Thing[b] can be synced applied despite Thing[a] not having successfully been synced, then it should not matter to Thing[b] whether any attempt has been made to sync Thing[a] -- that is, their relative order of application does not matter. > > ----- > > > The other example that comes to mind is: > > Thing[a] -> $might_contain_references -> Thing[b] > > This differs from above as variables are parse-order dependent and > collectors are not (right?), and variables may be undefined or undef and > collectors are... neither of those things (instead the graph is updated > directly when collectors return resources, I believe). > > A thought on semantic differencs from collectors: the value of a variable > is directly obveservable at evaluation time, and dependency chains can be > created based on this evaluation. Therefore I would posit that undef or > undefined variables in dependency chains are always an error state, whereas > empty collectors may or may not be. > I'm not sure about the details of the current behavior here, but I think you're raising a separate issue: how an expression with undefined value is interpreted when it appears as an operand of a chain operator. The value of a collector expression that happens to collect zero resources is well defined (as an empty collection), so this question is irrelevant to collectors in chain expressions. I would be fine with undefined chain operands being an error, however. John -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/923354a8-f230-4753-8cd9-5108c8729cbf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
