On 25/02/16 15:08, Gary Larizza wrote:
On Wednesday, February 24, 2016, Gary Larizza <g...@puppetlabs.com <mailto: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.
It is one of the troublesome cases for sure (there are more). In this case the problem is you can do nothing to protect against an error since you cannot have a condition on the query returning anything and you have given your ability to have any say in the matter leaving it do puppet to divine the intention.
If puppet takes the intention as there is supposed to be dependencies between things on the left to things on the right, then it should always short-circuit the empty man in the middle. Then neither of these cases are strictness violations (except in the reverse sense that "if you expect this to not create dependencies when there is an empty man in the middle you just got the opposite" (which we then warn about).
- 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/56CF12F3.2010808%40puppetlabs.com. For more options, visit https://groups.google.com/d/optout.
