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.

And, it makes sense that A -> [] and [] -> B would not be related since
they have no obvious syntax relationship.

Thanks,

Trevor

On Thu, Feb 25, 2016 at 6:12 PM, Henrik Lindberg <
henrik.lindb...@puppetlabs.com> wrote:

> On 25/02/16 23:50, Trevor Vaughan wrote:
>
>> I just want to make sure I'm reading this right.
>>
>> For the first scenario, noop means don't order anything, just do things
>> in whatever order they happen.
>>
>> And the second scenario is: don't fail B if A fails (don't create a
>> relationship), but do A before B
>>
>> Is this correct?
>>
>>
> I have problems understanding what you mean by noop and fail here.
>
> The fundamental question is, does this expression define the order of A
> and B?
>
> A -> [ ] -> B
>
> You can view it either as it defines the order [A, B], or that it does not
> and their partial order is unaffected.
>
> If you like the answer to be [A, B], does it bother you that the following
> is not the same thing:
>
> A -> [ ]
> [ ] -> B
>
> As that would not order them - because [ ] here can be seen as either
> first/last or "in the partial order that is defined elsewhere".
>
> Trying to make that define the order [A, B] is impossible since every
> resource starts out with the partial order [[], R, []] (nothing before R,
> nothing after R).
>
> - henrik
>
>
> If it is, I favor the second scenario as the default as it is more
>> intuitive to the 'ordered compile' of Puppet 3+.
>>
>> Thanks,
>>
>> Trevor
>>
>> On Thu, Feb 25, 2016 at 5:31 PM, Henrik Lindberg
>> <henrik.lindb...@puppetlabs.com <mailto:henrik.lindb...@puppetlabs.com>>
>>
>> wrote:
>>
>>     On 25/02/16 22:08, John Bollinger wrote:
>>
>>
>>
>>         On Thursday, February 25, 2016 at 8:55:01 AM UTC-6, Trevor
>>         Vaughan wrote:
>>
>>              Hmm.....
>>
>>              I think, as long as it is documented, then whatever behavior
>> is
>>              deterministic is fine.
>>              '
>>              I think that there is value in the following resolutions:
>>
>>              Notify['left'] -> [] -> Notify['right']
>>                 * Noop since there is nothing in []
>>
>>              Notify['left'] -> [] -> Notify['right']
>>              Notify['left'] -> Notify['right']
>>                 * First == Noop
>>                 * Second == Expected ordering
>>
>>
>>
>>         I flip-flopped a bit on this.  I started from the position that
>>         it would
>>         be inappropriate for
>>
>>         |
>>         Notify['left']->$stuff ->Notify['right']
>>         |
>>
>>         or
>>
>>         |
>>         Notify['left']->Stuff<||>->Notify['right']
>>         |
>>
>>         ever to fail to cause Notify['left'] to be applied before
>>         Notify['right'], as indeed it now does fail to do in the event
>>         that the
>>         stuff in the middle represents zero resources.  My basis there
>>         was that
>>         it is counterintuitive for such expressions to not establish
>>         relative
>>         ordering of the two Notifys.
>>
>>         Ultimately, however, that basis is completely subjective.
>>         Others might
>>         reasonably intuit that such an expression would have exactly the
>>         semantics it actually does have, which are roughly equivalent to
>>         those of
>>
>>         |
>>         Notify['left']->$stuff
>>         $stuff ->Notify['right']
>>         |
>>
>>         .  Upon reflection, this alternative is less magic.  It falls out
>>         naturally from understanding that chain operators associate from
>>         left to
>>         right, and that each binary chain expression /evaluates to/ the
>>         value of
>>         its right-hand operand.  That some people might find that behavior
>>         surprising is a consideration, but not a primary one for me.
>>
>>
>>     It depends on the operator if it is left or right associative and if
>>     it is cumulative. And also what the result of '(nothing) op
>>     (something)' results in.
>>
>>     if
>>        (nothing) -> X
>>        X -> (nothing)
>>
>>     both evaluate to X
>>
>>     as in
>>
>>        0 + 1
>>        1 + 0
>>
>>     Then empty man in the middle would be a noop.
>>
>>     If you consider the arrows to abstractly order a set of resources in
>>     an array which at the end of the chain defines the partial order of
>>     the resources it would be the same as doing array concatenation.
>>
>>     i.e.
>>     [A] + [] + [B] = [A, B]
>>
>>     So - it is all down to definition of the arrow operators; i.e.
>>     taste/most practical/least surprise.
>>
>>     - henrik
>>
>>
>>     --
>>
>>     Visit my Blog "Puppet on the Edge"
>>     http://puppet-on-the-edge.blogspot.se/
>>
>>     --
>>     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
>>     <mailto:puppet-dev%2bunsubscr...@googlegroups.com>.
>>     To view this discussion on the web visit
>>
>> https://groups.google.com/d/msgid/puppet-dev/56CF80DD.7010200%40puppetlabs.com
>> .
>>
>>     For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>>
>> --
>> Trevor Vaughan
>> Vice President, Onyx Point, Inc
>> (410) 541-6699
>>
>> -- This account not approved for unencrypted proprietary information --
>>
>> --
>> 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
>> <mailto:puppet-dev+unsubscr...@googlegroups.com>.
>> To view this discussion on the web visit
>>
>> https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUmvhYvCOift0Hn8vAGPyO89TmnyLty2mcB4R47h1fB3g%40mail.gmail.com
>> <
>> https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUmvhYvCOift0Hn8vAGPyO89TmnyLty2mcB4R47h1fB3g%40mail.gmail.com?utm_medium=email&utm_source=footer
>> >.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
>
> Visit my Blog "Puppet on the Edge"
> http://puppet-on-the-edge.blogspot.se/
>
> --
> 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/56CF8A4D.3070004%40puppetlabs.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699

-- This account not approved for unencrypted proprietary information --

-- 
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/CANs%2BFoXoXN%2BYzNDMNkRGWeHdM3o-EE-5qNAu%2B3P4WU%2BkuOdzZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to