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 Notify['left'] -> Undef -> <Whatever> * Error since Undef is in the relationship I would *love* to see an extension of the autorequire, etc... capabilities in the core relationship language. Notify['left'] --> Notify['right'] (Idea: double symbol means auto*. '--', '~~', etc...) * Notify happens as usual. If one, or both resources do not exist in the catalog, this is not an error. Yes, I know that this starts to expose some 'spooky action at a distance' features but, let's face it, that ship has sailed with logic flying in all over the place with Exported Resources, Orchestrator, Hiera Backends, ENCs, etc... Trevor On Thu, Feb 25, 2016 at 9:42 AM, Henrik Lindberg < henrik.lindb...@puppetlabs.com> wrote: > 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. > -- 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%2BFoUAX5gspif0MOv0Zwg%2Bxq39YZSWe40OEo6eqwAMMHigBg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
