date:20160225

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

2016-02-25 Thread 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] Announce: PuppetDB 3.2.4 available

2016-02-25 Thread Russell Mull



PuppetDB 3.2.4 - February 25, 2016

PuppetDB 3.2.4 Downloads



Available in native package format as part of Puppet Collection 1 (PC1). 
More information on the PC1 repositories is available here: 
http://bit.ly/1HQJDNb

Binary tarball: http://downloads.puppetlabs.com/puppetdb/

Source: http://github.com/puppetlabs/puppetdb

Please report feedback via the Puppet Labs tickets site by submitting a 
ticket with an “Affects Version/s” field of “PDB 3.2.4”: 
https://tickets.puppetlabs.com/browse/PDB

Documentation: http://docs.puppetlabs.com/puppetdb/3.2/

Puppet module: http://forge.puppetlabs.com/puppetlabs/puppetdb

PuppetDB 3.2.4 Release Notes



PuppetDB 3.2.4 is a backward-compatible security and bugfix release that 
fixes a

directory permissions issue, improves the performance of certain metrics

queries, and reduces the size of anonymized export tarballs.

More information on the specifics of the release can be found in the 
official release notes: 
https://docs.puppetlabs.com/puppetdb/3.2/release_notes.html 

Also see the related security advisory: 
https://puppetlabs.com/security/cve/puppetdb-feb-2016-advisory

Contributors

---

Andrew Roetker, Garrett Guillotte, Geoff Nichols, Isaac Eldridge, Ken 
Barber, Kurt Wall, Russell Mull, Ryan Senior, Sean P. McDonald, and Wyatt 
Alt

-- 
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/76a34635-8fbf-406d-bf55-a2cd97b1393a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2016-02-25 Thread 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?

2016-02-25 Thread 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?

2016-02-25 Thread 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?

2016-02-25 Thread 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?

2016-02-25 Thread 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?

2016-02-25 Thread 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?

2016-02-25 Thread 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?

[Puppet-dev] Announce: PuppetDB 3.2.4 available

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

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

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

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

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

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

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

9 matches

Site Navigation

Mail list logo

Footer information