Re: [Puppet-dev] Re: How strict do you want puppet to be?

[John Bollinger]

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 puppet-dev+unsubscr...@googlegroups.com.
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.

Re: [Puppet-dev] Re: How strict do you want puppet to be?

[Hunter Haugen]

> 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. 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.

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. Does
that occur in the real world? Not afaik.

-

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.

-- 
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/CAJaQvGAx1ACQjG3nmQq91hS40hwx8J9KN2Xz%3DG_kc30AsHMZsA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: How strict do you want puppet to be?

[John Bollinger]

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.
>


Now you're confusing me.  Chain expressions are a means for declaring 
resource relationships.  To the extent that failures of resources earlier 
in a chain prevent resources later in the same chain from being applied, 
that is a function of the resource relationships expressed by the chain.  
If the chain A -> [] -> B does express a direct or transitive relationship 
between A and B then failures in A prevent B from being applied.  If that 
chain does not express any relationship between A and B then it does not 
constrain their order of application.

It sounds, however, as if you are asking for an altogether new kind of 
ordering constraint, one which directs order of application but allows 
resources to be applied despite the failure of resources constrained to be 
applied earlier.  If that's so, then I'm afraid I don't see the point.  If 
a resource B can by synced successfully despite another resource A failing 
to sync, then how can it matter whether the attempt to sync A is made 
before the attempt to sync B?

If indeed that's what you're asking for, however, then rather than create a 
new kind of relationship, I think it would be better to create a way to 
declare that application of specific containers always succeeds or always 
fails, regardless of the outcome of applying whatever is declared within.  
Then you could wrap resource A in a container (e.g. a define) that succeeds 
whether A succeeds or not, and establish an ordinary relationship between 
that container and B.  I'm inclined to think that there would be other uses 
for such a feature, and rather than any new DSL syntax, the DSL interface 
to it could be implemented as a function.


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 puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/9a05acc5-cd89-48d8-90d5-5b2a9cd8cd35%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: How strict do you want puppet to be?

[Trevor Vaughan]

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
>> >
>>
>> 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 

[Puppet-dev] Re: How strict do you want puppet to be?

[Henrik Lindberg]

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
>
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
.
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

Re: [Puppet-dev] Re: How strict do you want puppet to be?

[Trevor Vaughan]

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?

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> 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.
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUmvhYvCOift0Hn8vAGPyO89TmnyLty2mcB4R47h1fB3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] Re: How strict do you want puppet to be?

[Henrik Lindberg]

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.
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.

Re: [Puppet-dev] Re: How strict do you want puppet to be?

[John Bollinger]

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.

Moreover, this isn't really all that novel a problem.  Consider, for 
instance, this Ruby code:

a = 0
b = 1
c = 2
print "oops" if a < b < c  # NoMethodError

Note also that this C analog actually prints the result you might naively 
expect:

#include 
int main() {
  int a = 0, b = 1, c = 2;
  if (a < b < c) puts("ok");
  return 0;
}

.  Its output is the same if you swap a and b, though, yet it differs if 
you instead swap a and c.  (Hint for non-C-ers: the Ruby result gives a 
good clue to what happens in the C example.)

There might be more grounds for argument if the chain operators were just 
now being designed from scratch, but I see no justification for changing 
their reasonable and established behavior, especially since it is 
conceivable that the current behavior is in fact being intentionally 
leveraged at some sites.  I favor the resolutions Trevor presented.

 

> Notify['left'] -> Undef -> 
>   * Error since Undef is in the relationship
>


The Undef case is to some extent a separate question.  I'm inclined to 
agree again that it should be an error for an operand of a chain operator 
to be undefined, but if that's not how it works now then I am ambivalent 
about whether the behavior should be changed.


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 puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/57a6a258-b4b9-45a5-bf2c-cca8ef5cea74%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: How strict do you want puppet to be?

[Hunter Haugen]

On Thu, Feb 25, 2016 at 12:44 PM, Hunter Haugen 
wrote:

> I am following up with a runtime type strictness thing.
>
>>
>> If you have a construct like this in your manifests:
>>
>> Notify['left'] -> $stuff -> Notify['right']
>>
>>
> Thansk for asking! For me, I would prefer the ordering to follow left ->
> right, and not error or warn.
>
> If I have expressed Notify['left'] -> $stuff -> Notify['right'] then the
> ordering of left then right should be possible in all circumstances.
> Whether it is required or not when $stuff is empty is another matter, but
> it doesn't impact the user if all resources succeed.
>
> Technologically, the references could be explicit references or
> collectors, and collectors can produce zero references, and this is
> actually DESIRED by me, as recently as yesterday. My use case was chaining
> lots of collections of optional defined types Like `A <||> -> B <||> -> C
> <||> D <||>` where B/C/D are optional, but A must always come before B/C/D
> and D must always come after A/B/C. In minimal cases, only A and D may be
> declared, so I ended up doing A <||> -> D <||> ; A <||> -> B <||> -> D <||>
> ; A <||> -> C <||> -> D <||> which is overly verbose.
>

This is abstract, but maybe an example could help. For reference, my
current manifest is
https://github.com/hunner/puppetlabs-tomcat/blob/e3d8a56876cb072b60468ded86490051059a56a1/manifests/instance/dependencies.pp
though is still a work in progress.

And this behavior could be taken off-thread and put in a ticket if you'd
rather discuss the outcome separately, since it's not directly about
warning and erroring on --strict

>
> It's worth noting that I ran into the above case because I expected empty
> collectors to maintain the chain, and was surprised when resources were
> evaluated out of order.
>
> Producing a whit or something similar to contain the list of zero or more
> references would give the dag the structure it needs to maintain ordering
> even when an element in the chain is empty.
>

-- 
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/CAJaQvGDV0Te_91NCW32dCVzXyiBgLyQwgFK%2Bbf06Q2NdtNM%3DVg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: How strict do you want puppet to be?

[Hunter Haugen]

I am following up with a runtime type strictness thing.

>
> If you have a construct like this in your manifests:
>
> Notify['left'] -> $stuff -> Notify['right']
>
>
Thansk for asking! For me, I would prefer the ordering to follow left ->
right, and not error or warn.

If I have expressed Notify['left'] -> $stuff -> Notify['right'] then the
ordering of left then right should be possible in all circumstances.
Whether it is required or not when $stuff is empty is another matter, but
it doesn't impact the user if all resources succeed.

Technologically, the references could be explicit references or collectors,
and collectors can produce zero references, and this is actually DESIRED by
me, as recently as yesterday. My use case was chaining lots of collections
of optional defined types Like `A <||> -> B <||> -> C <||> D <||>` where
B/C/D are optional, but A must always come before B/C/D and D must always
come after A/B/C. In minimal cases, only A and D may be declared, so I
ended up doing A <||> -> D <||> ; A <||> -> B <||> -> D <||> ; A <||> -> C
<||> -> D <||> which is overly verbose.

It's worth noting that I ran into the above case because I expected empty
collectors to maintain the chain, and was surprised when resources were
evaluated out of order.

Producing a whit or something similar to contain the list of zero or more
references would give the dag the structure it needs to maintain ordering
even when an element in the chain is empty.

-- 
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/CAJaQvGBRcnsSkVFYWTqMaq26RKiz8JKugqQvaS8ea%2BauByHAfQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] Re: How strict do you want puppet to be?

[Henrik Lindberg]

On 25/02/16 15:08, Gary Larizza wrote:



On Wednesday, February 24, 2016, Gary Larizza > wrote:



On Wed, Feb 24, 2016 at 10:47 PM, Henrik Lindberg
> wrote:

On 23/02/16 01:47, Henrik Lindberg wrote:

Hi, I am thinking ahead a bit regarding puppet 5 and how we
should deal
with all the requests for features that require
deprecations. (There are
some related things like requests for additional validation
and warnings
that are different from deprecations).

In the past we merrily started issuing deprecation warnings,
but the
community pretty unanimously said "stop doing that" we
cannot deal with
all of those warnings. Since then we then pretty much
stopped doing
deprecation warnings.

There has also been a long standing wish for a "strict mode"
in puppet,
that like a harsh teacher would point out every itty-bitty
problem.

So - what should we do?

In PUP-5889 I have described an idea. This is the text from
that ticket
as it stands right now.

PUP-5889

-
Add a flag --strict to puppet settings. When in effect this
will turn on
--strict_variables, and will also enable other "helpful" but
undesirable
behavior. (Each such behavior to be defined in a separate
ticket).

The semantics of this flag should be:

* '--strict=ignore'; no strictness checks are to be
performed, nothing
is reported.

* '--strict=warn'; strictness checks are performed, they are
reported as
warnings, individually configurable warnings follow their
own setting
(i.e. if they are added to disabled_warnings).

* '--strict=errors'; strictness checks are performed, they
are reported
as errors and stop the execution. Further configuration to error
individually is not supported.

When we add this we promise to not change the set of things
that lead to
warning/error in .z releases, but we reserve the right to do
so for .x
releases. The idea being is that you can safely accept
updates for .z
without having to do anything. For .x releases you may need
to step back
to '--strict=warning' and then correct the problem before
going back to
'--strict=error'.

This scheme should cater to those that are pedantic about
following best
practices and not using deprecated features while those that
only care
at major version boundaries can do so in peace without being
bothered
with lots of deprecation warnings.

--

What do you think about this idea? Control all strictness and
deprecation warnings/errors with one flag, and handle
individual ones
(where applicable) by disabling those checks.

The benefit for us developing puppet is that we can
introduce the new
behavior much sooner and we do not need to add flags for
each and every
kind of validation/deprecation. This means we are more
likely to improve
things as we are not holding off until the very last release
in a major
series (and where inevitably some tickets will not make it).

Ironically, if this feature is liked it will make it into
4.5.0 which
may be the last in the 4.x series, but no decision has been
made yet.

- henrik


I am following up with a runtime type strictness thing.

If you have a construct like this in your manifests:

Notify['left'] -> $stuff -> Notify['right']

and at runtime $stuff happens to be an empty array, puppet
currently silently skips the middle part, and thus 'left' and
'right' are not ordered via the dependency in the middle.

Should it warn? Is it an error? (I understand there will be a
difference of opinion here if it should always be one or the
other, or if it should be controlled by the --strict option). I
just wanted to include it as an example of something that is not
caught by static checking at parse/validation time.


Oh the chain syntax...   

Re: [Puppet-dev] Re: How strict do you want puppet to be?

[Gary Larizza]

On Wed, Feb 24, 2016 at 10:47 PM, Henrik Lindberg <
henrik.lindb...@puppetlabs.com> wrote:

> On 23/02/16 01:47, Henrik Lindberg wrote:
>
>> Hi, I am thinking ahead a bit regarding puppet 5 and how we should deal
>> with all the requests for features that require deprecations. (There are
>> some related things like requests for additional validation and warnings
>> that are different from deprecations).
>>
>> In the past we merrily started issuing deprecation warnings, but the
>> community pretty unanimously said "stop doing that" we cannot deal with
>> all of those warnings. Since then we then pretty much stopped doing
>> deprecation warnings.
>>
>> There has also been a long standing wish for a "strict mode" in puppet,
>> that like a harsh teacher would point out every itty-bitty problem.
>>
>> So - what should we do?
>>
>> In PUP-5889 I have described an idea. This is the text from that ticket
>> as it stands right now.
>>
>> PUP-5889
>> -
>> Add a flag --strict to puppet settings. When in effect this will turn on
>> --strict_variables, and will also enable other "helpful" but undesirable
>> behavior. (Each such behavior to be defined in a separate ticket).
>>
>> The semantics of this flag should be:
>>
>> * '--strict=ignore'; no strictness checks are to be performed, nothing
>> is reported.
>>
>> * '--strict=warn'; strictness checks are performed, they are reported as
>> warnings, individually configurable warnings follow their own setting
>> (i.e. if they are added to disabled_warnings).
>>
>> * '--strict=errors'; strictness checks are performed, they are reported
>> as errors and stop the execution. Further configuration to error
>> individually is not supported.
>>
>> When we add this we promise to not change the set of things that lead to
>> warning/error in .z releases, but we reserve the right to do so for .x
>> releases. The idea being is that you can safely accept updates for .z
>> without having to do anything. For .x releases you may need to step back
>> to '--strict=warning' and then correct the problem before going back to
>> '--strict=error'.
>>
>> This scheme should cater to those that are pedantic about following best
>> practices and not using deprecated features while those that only care
>> at major version boundaries can do so in peace without being bothered
>> with lots of deprecation warnings.
>> --
>>
>> What do you think about this idea? Control all strictness and
>> deprecation warnings/errors with one flag, and handle individual ones
>> (where applicable) by disabling those checks.
>>
>> The benefit for us developing puppet is that we can introduce the new
>> behavior much sooner and we do not need to add flags for each and every
>> kind of validation/deprecation. This means we are more likely to improve
>> things as we are not holding off until the very last release in a major
>> series (and where inevitably some tickets will not make it).
>>
>> Ironically, if this feature is liked it will make it into 4.5.0 which
>> may be the last in the 4.x series, but no decision has been made yet.
>>
>> - henrik
>>
>>
> I am following up with a runtime type strictness thing.
>
> If you have a construct like this in your manifests:
>
> Notify['left'] -> $stuff -> Notify['right']
>
> and at runtime $stuff happens to be an empty array, puppet currently
> silently skips the middle part, and thus 'left' and 'right' are not ordered
> via the dependency in the middle.
>
> Should it warn? Is it an error? (I understand there will be a difference
> of opinion here if it should always be one or the other, or if it should be
> controlled by the --strict option). I just wanted to include it as an
> example of something that is not caught by static checking at
> parse/validation time.
>

Oh the chain syntax...   I have a couple of reactions:

If $stuff is an empty array, it's technically NOT undef, so it has a
'value', but I dunno why you'd put that in a dependency chain.  In Puppet,
I like that dependencies are expressed for a reason - you went to the
effort to express it because it was necessary.  So if you did the above and
a dependency was not established, my knee-jerk reaction is to consider it
at LEAST unexpected behavior which should be warned (if not an error).  I'd
consider it an error though - you intended a dependency and one was not
established.


>
> Statically we could possibly check if the outcome is statically known
> or if there is a potential problem (i.e. where evaluation can lead to
> "empty thing in the middle"). But I am not sure what the quality of that
> would be and how expensive it would be to implement.
>
> There are number of such cases where puppet is trying to be helpful and
> ends up with a messy situation that it silently ignores or goofs up on.
>
> - henrik
>
>
>
> --
>
> Visit my Blog "Puppet on the Edge"
> 

[Puppet-dev] Re: How strict do you want puppet to be?

[Henrik Lindberg]

On 23/02/16 01:47, Henrik Lindberg wrote:

Hi, I am thinking ahead a bit regarding puppet 5 and how we should deal
with all the requests for features that require deprecations. (There are
some related things like requests for additional validation and warnings
that are different from deprecations).

In the past we merrily started issuing deprecation warnings, but the
community pretty unanimously said "stop doing that" we cannot deal with
all of those warnings. Since then we then pretty much stopped doing
deprecation warnings.

There has also been a long standing wish for a "strict mode" in puppet,
that like a harsh teacher would point out every itty-bitty problem.

So - what should we do?

In PUP-5889 I have described an idea. This is the text from that ticket
as it stands right now.

PUP-5889
-
Add a flag --strict to puppet settings. When in effect this will turn on
--strict_variables, and will also enable other "helpful" but undesirable
behavior. (Each such behavior to be defined in a separate ticket).

The semantics of this flag should be:

* '--strict=ignore'; no strictness checks are to be performed, nothing
is reported.

* '--strict=warn'; strictness checks are performed, they are reported as
warnings, individually configurable warnings follow their own setting
(i.e. if they are added to disabled_warnings).

* '--strict=errors'; strictness checks are performed, they are reported
as errors and stop the execution. Further configuration to error
individually is not supported.

When we add this we promise to not change the set of things that lead to
warning/error in .z releases, but we reserve the right to do so for .x
releases. The idea being is that you can safely accept updates for .z
without having to do anything. For .x releases you may need to step back
to '--strict=warning' and then correct the problem before going back to
'--strict=error'.

This scheme should cater to those that are pedantic about following best
practices and not using deprecated features while those that only care
at major version boundaries can do so in peace without being bothered
with lots of deprecation warnings.
--

What do you think about this idea? Control all strictness and
deprecation warnings/errors with one flag, and handle individual ones
(where applicable) by disabling those checks.

The benefit for us developing puppet is that we can introduce the new
behavior much sooner and we do not need to add flags for each and every
kind of validation/deprecation. This means we are more likely to improve
things as we are not holding off until the very last release in a major
series (and where inevitably some tickets will not make it).

Ironically, if this feature is liked it will make it into 4.5.0 which
may be the last in the 4.x series, but no decision has been made yet.

- henrik



I am following up with a runtime type strictness thing.

If you have a construct like this in your manifests:

Notify['left'] -> $stuff -> Notify['right']

and at runtime $stuff happens to be an empty array, puppet currently 
silently skips the middle part, and thus 'left' and 'right' are not 
ordered via the dependency in the middle.


Should it warn? Is it an error? (I understand there will be a difference 
of opinion here if it should always be one or the other, or if it should 
be controlled by the --strict option). I just wanted to include it as an 
example of something that is not caught by static checking at 
parse/validation time.


Statically we could possibly check if the outcome is statically known
or if there is a potential problem (i.e. where evaluation can lead to 
"empty thing in the middle"). But I am not sure what the quality of that 
would be and how expensive it would be to implement.


There are number of such cases where puppet is trying to be helpful and 
ends up with a messy situation that it silently ignores or goofs up on.


- 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/56CE8764.2000703%40puppetlabs.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] Re: How strict do you want puppet to be?

[Henrik Lindberg]

On 24/02/16 20:24, Walter Heck wrote:

On Wednesday, February 24, 2016 at 11:49:17 AM UTC+1, Trevor Vaughan wrote:

I'm also a fan of per module which can override a global setting.

If it could be part of the metadata.json, that would be ideal and
would allow for attestation on the Forge if appropriate.

I gave this some thought and I would be heavily against this: a module
doesn't get to decide for it's consumers wether they will want to run in
strict mode. The person running the puppetmaster should decide this,
preferrably on a per environment base.

What I do think would be good to have in metadata.json is a flag that
says which modes the module supports for which puppet versions. That way
it can be displayed on the forge for instance and I can choose in
advance to only download modules supporting strict mode.



Good idea. Ideally the forge should validate the module by parsing 
everything in it and automatically assert if it passes strict without 
warnings for the version the module states it supports.


This would be a reasonable measure of quality.

Forge can however not validate the runtime strictness (it would need to 
evaluate / compile and that is not guaranteed to find all such problems.


We naturally want to make as much as possible be found when parsing and 
validating statically.


If the forge ere to check strictness for statically discoverable things, 
would you need to manually state strictness in metadata.json?


- henrik


cheers,

--
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/2a0bec94-ff66-4e0f-9930-a76a193a5f88%40googlegroups.com
.
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/56CE8499.1020904%40puppetlabs.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: How strict do you want puppet to be?

[Trevor Vaughan]

+1 to the mode support in the metadata.json

Dependency checking will be more fun.

Trevor

On Wed, Feb 24, 2016 at 2:24 PM, Walter Heck 
wrote:

> On Wednesday, February 24, 2016 at 11:49:17 AM UTC+1, Trevor Vaughan wrote:
>>
>> I'm also a fan of per module which can override a global setting.
>>
>> If it could be part of the metadata.json, that would be ideal and would
>> allow for attestation on the Forge if appropriate.
>>
> I gave this some thought and I would be heavily against this: a module
> doesn't get to decide for it's consumers wether they will want to run in
> strict mode. The person running the puppetmaster should decide this,
> preferrably on a per environment base.
>
> What I do think would be good to have in metadata.json is a flag that says
> which modes the module supports for which puppet versions. That way it can
> be displayed on the forge for instance and I can choose in advance to only
> download modules supporting strict mode.
>
> cheers,
>
> --
> 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/2a0bec94-ff66-4e0f-9930-a76a193a5f88%40googlegroups.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%2BFoUyDfuZLBCM2KFj0uXvg-bN2kJpDxqdY%3D7mf-jdEyBNhw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: How strict do you want puppet to be?

[Walter Heck]

On Wednesday, February 24, 2016 at 11:49:17 AM UTC+1, Trevor Vaughan wrote:
>
> I'm also a fan of per module which can override a global setting.
>
> If it could be part of the metadata.json, that would be ideal and would 
> allow for attestation on the Forge if appropriate.
>
I gave this some thought and I would be heavily against this: a module 
doesn't get to decide for it's consumers wether they will want to run in 
strict mode. The person running the puppetmaster should decide this, 
preferrably on a per environment base.

What I do think would be good to have in metadata.json is a flag that says 
which modes the module supports for which puppet versions. That way it can 
be displayed on the forge for instance and I can choose in advance to only 
download modules supporting strict mode.

cheers,

-- 
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/2a0bec94-ff66-4e0f-9930-a76a193a5f88%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: How strict do you want puppet to be?

[Ryan Whitehurst]

On Wed, Feb 24, 2016 at 5:58 AM, Henrik Lindberg
 wrote:
> On 24/02/16 11:49, Trevor Vaughan wrote:
>>
>> I'm also a fan of per module which can override a global setting.
>>
>> If it could be part of the metadata.json, that would be ideal and would
>> allow for attestation on the Forge if appropriate.
>>
>> The global --strict=off should override any module-level setting.
>>
>
>
> I have been thinking about this for a bit now. Unfortunately it is going to
> be very difficult to achieve any sort of "per module" handling of
> strictness. While it can be applied statically to parsing, most of the
> deprecations are about semantic problems that occur at evaluation time and
> in places where there is absolutely no clue about the origin of the logic -
> or for that matter a mix of modules and data sources that together resulted
> in a state that in the future will be an error.

I'm not even completely sure what the semantics of "per-module" would
be in practice anyway. On the forge, like Trevor suggested, any code
quality metric that uses this should always be checking everything
that --strict checks; you shouldn't be able to say "no, I want to
write less-than-ideal or outdated code and have my module appear to
have the same code quality as modules that follow latest best
practices". In actual deployments (whether testing or production),
saying "I only want this information from my custom code, not these
forge modules" is useful, but the semantics of a global setting and
per-module would be hard. How would I say both "I want deprecation
warnings for all my code unless the author disabled strict checking
because I'm practical and don't need large swaths of warnings for code
I didn't write that just add noise" and "I want to force deprecation
warnings everywhere because I'm upgrading major versions and if I
don't catch these now it will be a failure when I upgrade"?

I think global and per-environment are sufficient. Most of the time, I
suspect --strict=warn is going to be all you want anyway.

> I think we will start with just a global --strict flag that can be used in
> combination with tools like puppet parser validate at authoring time to
> catch problems. In production I think you always set --strict=off since you
> must already have reviewed and tested the logic that is in production, being
> reminded about warnings for all nodes every 30 minutes is not really what
> you want.

This makes sense. If you had all your code to the point where it
generated no --strict warnings/errors, you might use --strict=error to
enforce keeping it that way. As well, if you don't have (sufficient)
tests for your code (like a lot of internal code), you might use
--strict=warn so that those warnings were surfaced somewhere even if
you missed certain cases.

> It makes a lot of sense to set it per environment. We do have issues with
> that though; when you want to treat things differently in development and
> production as you must modify a file that is checked in and you must
> remember to not check in the settings that are only applicable when an
> environment is in test or development state. Still better than just a global
> flag.

This isn't very different from setting the parser via environment.conf
in 3.8, so I think it's fine. Lots of people still don't use some sort
of vcs branching workflow,, so this issue wouldn't really affect them
anyway.

-- 
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/CAHTHiAFa%2Bxs3dFeQ88PukS3M-upcqDufiZP3DT3XDo1ZW-paxg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] Re: How strict do you want puppet to be?

[Henrik Lindberg]

On 24/02/16 11:49, Trevor Vaughan wrote:

I'm also a fan of per module which can override a global setting.

If it could be part of the metadata.json, that would be ideal and would
allow for attestation on the Forge if appropriate.

The global --strict=off should override any module-level setting.




I have been thinking about this for a bit now. Unfortunately it is going 
to be very difficult to achieve any sort of "per module" handling of 
strictness. While it can be applied statically to parsing, most of the 
deprecations are about semantic problems that occur at evaluation time 
and in places where there is absolutely no clue about the origin of the 
logic - or for that matter a mix of modules and data sources that 
together resulted in a state that in the future will be an error.


I think we will start with just a global --strict flag that can be used 
in combination with tools like puppet parser validate at authoring time 
to catch problems. In production I think you always set --strict=off 
since you must already have reviewed and tested the logic that is in 
production, being reminded about warnings for all nodes every 30 minutes 
is not really what you want.


It makes a lot of sense to set it per environment. We do have issues 
with that though; when you want to treat things differently in 
development and production as you must modify a file that is checked in 
and you must remember to not check in the settings that are only 
applicable when an environment is in test or development state. Still 
better than just a global flag.


- 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/56CDB6FB.7040105%40puppetlabs.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: How strict do you want puppet to be?

[Trevor Vaughan]

I'm also a fan of per module which can override a global setting.

If it could be part of the metadata.json, that would be ideal and would
allow for attestation on the Forge if appropriate.

The global --strict=off should override any module-level setting.

Thanks,

Trevor

On Tue, Feb 23, 2016 at 9:03 PM, Henrik Lindberg <
henrik.lindb...@puppetlabs.com> wrote:

> On 24/02/16 00:27, Ryan Whitehurst wrote:
>
>> On Tue, Feb 23, 2016 at 3:22 PM, Walter Heck 
>> wrote:
>>
>>> On Tuesday, February 23, 2016 at 11:31:18 PM UTC+1, Ben Ford wrote:
>>>

 Would it be possible in this scheme to mark strict mode per class? I
 could
 mark my own code as being strict and therefore get compile time failures
 when I make a typo myself, but wouldn't have to enforce that on all
 third
 party code.

>>>
>>>
>>> Instead of per class I'd like to be able to set it per (module)path. We
>>> use
>>> r10k and split the role and profile modules to their own modulepath
>>> (typically called 'site'), all 3rd party modules live in the standard
>>> modulepath.
>>>
>>> I could also imagine people wanting to set this per environment.
>>>
>>> Lastly, I think --strict=ignore should be --strict=off, but that's
>>> personal
>>> preference.
>>>
>>
>> I agree with everything Walter is saying here. Per-class would be
>> difficult, but if there was a way to set it per-modulepath, you could
>> accomplish what Ben is asking for. It should also definitely be an
>> available setting in environment.conf.
>>
>>
> By per modulepath, do you mean per directory containing modules?
> the module path consists of multiple directories and the environment has
> one.
>
> Would adding strictness to the module metadata.json work for you?
> Then each module author decides how clean their code is.
>
> --strict=off seems a bit nicer to me as well than does
>> --strict=ignore, but I don't care much.
>>
>> I also bought the --strict='off' since in many cases it also actually
> turns of the checking (but not always, and it may just be a
> "ignore"/suppression of the logging.
>
> My first thought is that --strict=warn would make a sensible default
>> in this scenario, as it's most similar to puppet's traditional
>> behavior of showing deprecation warnings every time.
>>
>>
> In the PR that is up, --strict=warning is the default.
>
>
> --
>
> 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/56CD0F8D.1010201%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%2BFoXQSVDKK2M5mXmN8rpAU-xZa0-%3DvOuPCWyYkakwRXtVoA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] Re: How strict do you want puppet to be?

[Henrik Lindberg]

On 24/02/16 00:27, Ryan Whitehurst wrote:

On Tue, Feb 23, 2016 at 3:22 PM, Walter Heck  wrote:

On Tuesday, February 23, 2016 at 11:31:18 PM UTC+1, Ben Ford wrote:


Would it be possible in this scheme to mark strict mode per class? I could
mark my own code as being strict and therefore get compile time failures
when I make a typo myself, but wouldn't have to enforce that on all third
party code.



Instead of per class I'd like to be able to set it per (module)path. We use
r10k and split the role and profile modules to their own modulepath
(typically called 'site'), all 3rd party modules live in the standard
modulepath.

I could also imagine people wanting to set this per environment.

Lastly, I think --strict=ignore should be --strict=off, but that's personal
preference.


I agree with everything Walter is saying here. Per-class would be
difficult, but if there was a way to set it per-modulepath, you could
accomplish what Ben is asking for. It should also definitely be an
available setting in environment.conf.



By per modulepath, do you mean per directory containing modules?
the module path consists of multiple directories and the environment has 
one.


Would adding strictness to the module metadata.json work for you?
Then each module author decides how clean their code is.


--strict=off seems a bit nicer to me as well than does
--strict=ignore, but I don't care much.

I also bought the --strict='off' since in many cases it also actually 
turns of the checking (but not always, and it may just be a 
"ignore"/suppression of the logging.



My first thought is that --strict=warn would make a sensible default
in this scenario, as it's most similar to puppet's traditional
behavior of showing deprecation warnings every time.



In the PR that is up, --strict=warning is the default.


--

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/56CD0F8D.1010201%40puppetlabs.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] Re: How strict do you want puppet to be?

[Henrik Lindberg]

On 24/02/16 00:22, Walter Heck wrote:

On Tuesday, February 23, 2016 at 11:31:18 PM UTC+1, Ben Ford wrote:

Would it be possible in this scheme to mark strict mode per class? I
could mark my own code as being strict and therefore get compile
time failures when I make a typo myself, but wouldn't have to
enforce that on all third party code.


Instead of per class I'd like to be able to set it per (module)path. We
use r10k and split the role and profile modules to their own modulepath
(typically called 'site'), all 3rd party modules live in the standard
modulepath.

I could also imagine people wanting to set this per environment.



Need to think about that for a bit. It makes it a lot more complicated.
Multiple paths etc. and where to specify them etc.


Lastly, I think --strict=ignore should be --strict=off, but that's
personal preference.



I think that is a good point. Will use 'off' instead of 'ignore'.


great idea, hope to see it come to life sooner rather then later :)



There is a PR up already :-)

- 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/56CD0E58.4020708%40puppetlabs.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] Re: How strict do you want puppet to be?

[Henrik Lindberg]

On 23/02/16 23:31, Ben Ford wrote:

Would it be possible in this scheme to mark strict mode per class? I
could mark my own code as being strict and therefore get compile time
failures when I make a typo myself, but wouldn't have to enforce that on
all third party code.



Good idea, you probably also need to be able to override because you may 
want to assert the quality of things you are using from 3d parties, 
either report the issues or fix and contribute back.


- 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/56CD0DD3.2050806%40puppetlabs.com.
For more options, visit https://groups.google.com/d/optout.