On Wednesday, February 24, 2016, Gary Larizza <g...@puppetlabs.com> wrote:
> > > On Wed, Feb 24, 2016 at 10:47 PM, Henrik Lindberg < > henrik.lindb...@puppetlabs.com > <javascript:_e(%7B%7D,'cvml','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. > As I was thinking overnight, one hack we abused early on was this: Package<|title == 'glibc'|> -> Class['fpm'] -> Class['apache'] The first being a search in the event the package was in the catalog, it should then have a dependency. If it is NOT, then no worries (this module shouldn't manage the package, but should come AFTER it if it IS in the catalog). This violates my response above and was something we needed largely before we had profiles (since that logic should go higher). I dunno whether this is "strict" or not. > >> >> 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 >> <javascript:_e(%7B%7D,'cvml','puppet-dev%2bunsubscr...@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. >> > > > > -- > Gary Larizza > Professional Services Engineer > Puppet Labs > > http://garylarizza.com > -- Gary Larizza Professional Services Engineer Puppet Labs http://garylarizza.com -- 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/CAMQzncKxG4wKqZP5bRC2zwDwRuyzMRJCrADLQiRrH3%2BZWcCqZw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
