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.
