On Mon, 24 Oct 2016 at 09:53 Alex Schultz <[email protected]> wrote:
> On Mon, Oct 24, 2016 at 10:40 AM, Erik Dalén > <[email protected]> wrote: > > > > > > On Mon, 24 Oct 2016 at 09:32 <[email protected]> wrote: > >> > >> > >> > >> On Friday, October 21, 2016 at 12:48:44 PM UTC-6, David Schmitt wrote: > >>> > >>> Hi, > >>> > >>> thank you for voicing your feedback. I can't do my work without it. > >>> > >>> On Thursday, October 20, 2016 at 10:49:45 AM UTC-7, [email protected] > >>> wrote: > >>>> > >>>> So I've recently noticed the deprecation notices for the validate_* > and > >>>> is_* functions withing stdlib. As a consumer of the stdlib who > currently > >>>> needs to continue to support puppet 3 and hasn't moved to puppet 4 > typing > >>>> for ~40 modules, this is a giant pain. > >>> > >>> > >>> If you are not yet prepared to make the switch, please stay with stdlib > >>> 4.12. > >>> > >>>> > >>>> Additionally we do not require (nor leverage) any of the old edge > cases > >>>> that are trying to continue to be maintained under the validate_legacy > >>>> function. > >>> > >>> > >>> validate_legacy and the Compat types are not supposed to continue to > >>> maintain the mess that were the validate_ functions. They are designed > to > >>> help you migrade in an incremental fashin, to leverage the new > datatypes, > >>> without forcing your complete installation to switch ot once into the > new > >>> world. If you have that kind of control over your modules, or you > already > >>> know that you're hitting none of the edge cases, you can of course > choose to > >>> do the switch in a single step. > >>> > >>>> > >>>> Is there a reason we can't just keep these is_* and validate_* > >>>> functions as is without the deprecation and/or just fix these in a > newer > >>>> version of stdlib? > >>> > >>> > >>> You can. Stay with stdlib 4.12. > >> > >> > >>> > >>> > >>>> > >>>> Is there some additional info as to why this decision was made? > >>> > >>> > >>> We want to start using the "new" puppet 4 features in the supported > >>> modules to show off the improvements you can gain through them. The > >>> deprecation and validate_legacy functions are intended to help the > whole > >>> ecosystem make this transition without having a flag day where > everyone has > >>> to switch. > >>> > >>> Using datatypes has a number of advantages over the validate functions: > >>> * high expressivity: look through the Compat types to see what the > >>> functions *actually* tested. They accept surprising types and leak > weird > >>> edge cases. Using datatypes removes a huge trap, and allows much > stricter > >>> specifications. > >>> * documentability: puppet-strings will surface datatypes in the > generated > >>> HTML. validate method calls are invisible. > >>> * core features: you can leverage the expressivity of datatypes using > the > >>> =~ match operator and assert_type everywhere you previously used > validate > >>> and is functoins, and the results have a much better chance of meeting > >>> everyone's expectations > >>> * extensiiblity: it is very easy to define custom types that match a > >>> module's domain, while it is very obscure to create your own validate > >>> functions. > >>> > >> > >> > >> Shouldn't these types of deprecation occur in a major version like in > the > >> 5.x series? I get the desire to move forward on these types of changes > but > >> the problem I have is mostly with the forced (and silent) > implementation of > >> these things mid 4.x. Swapping out these changes mid 4.x series is not > a > >> very good transition path for the end user. The problem I ran into > while > >> attempting to address these deprecations is that the validate_legacy > does > >> not exist until 4.13 which would force our minimum required stdlib from > the > >> current >= 4.0.0 < 5.0.0 to >= 4.13.0 < 5.0.0. I also don't think the > >> validate_legacy works under puppet 3. See > >> > http://logs.openstack.org/71/389271/1/check/gate-puppet-aodh-puppet-unit-3.8-centos-7/e89cc6b/console.html.gz#_2016-10-20_16_36_40_481087 > >> > >> The stdlib module is so ingrained in the community, I just think this > >> transition needs better thought around the impact to the end user. Just > >> pinning to <= 4.12.0 is not a quality answer because it just delays the > >> problem and can lead to incompatibilities between modules that continue > to > >> attempt to support both puppet 3 and 4. Puppet 3 is not EOL just yet and > >> enterpise customers are always late adopters so realistically these > types of > >> issues will only get larger for the foreseeable future. Unfortunately > for > >> the puppet openstack modules which is what I'm working on specifically, > we > >> won't be officially dropping puppet 3 support until after the current > cycle > >> which ends in March 2017 and we may need newer version of stdlib. > >> > >> This just seems like something that would be better suited for the next > >> major version than trying to do it mid stdlib 4.x and let people opt in > to > >> it as puppet 3 support fully dies off. > > > > > > Marked deprecated != removed. > > > > They are marked as deprecated now so the removal can actually happen in > the > > 5.0.0 release. > > The warning message can be ignored unless you plan on upgrading to the > next > > major version soon, or you can stay on a lower version to avoid getting > the > > warnings. > > > > Yea it's not removed but it's about consideration for the end user and > how they will now be flooded with warnings unless they do a bunch of > configurations to silence them (bad UX and probably a bad idea) or > find all the instances of the deprecated functions and update them if > they can (also bad UX). It would have been beneficial to add when it > will be removed in such messaging to set expectations. > > As an aside we recently got nailed when puppetlabs-ntp became no > longer puppet3 compatible on master prior to the new version being > released. As operators and developers, these incompatible transitions > really need to be well thought out on their impact. I can't count the > number of times we've been hit when someone decided to change their > gem (or ruby) dependencies mid release cycle and it breaks everything > even if we don't actually consume any code from that module. Sorry > it's a major pet peeve of mine when we have to drop everything and go > figure out who's doing breaking changes mid cycle and either pin or > find a work around because of backwards incompatibilities. > This sounds like you want a stable environment but yet you are tracking master for your dependencies. Just wait with upgrading until you have time to do it instead of all the time :) > > Thanks, > -Alex > > >> > >> Thanks, > >> -Alex > >> > >> p.s. I'm not sure that "if $var =~ Stdlib::Compat::Array" is nearly as > >> convenient (or readable) as if is_array($var) and trying to use standard > >> types instead of just validate_re is just painful. > >> > >> > >>>> > >>>> Having to go through our modules and switch out to the validate_legacy > >>>> functions is an effort we don't have the resources to undertake and > the > >>>> deprecation notices aren't something we can live with as they make it > very > >>>> hard to figure out when something actually breaks. > >>> > >>> > >>> Please see the documentation for the deprecation function in the stdlib > >>> readme on how to turn on/off deprecations in different situations (via > >>> puppet configuration on your master, or a environment variable during > >>> testing). You always have the possibility to stay on stdlib 4.12 until > you > >>> are ready to start your upgrade project. > >>> > >>>> > >>>> Additionally I'd like to point out that the deprecation notices make > it > >>>> next to impossible to figure out what is deprecated, see > >>>> > http://logs.openstack.org/89/388589/1/gate/gate-puppet-openstack-integration-4-scenario001-tempest-centos-7/fc2567b/console.html#_2016-10-19_22_24_59_667975 > >>>> > >>> > >>> Crap. I missed that one. I'm currently at puppetconf, and travelling > home > >>> afterwards, so I won't be able to look into it immediately, but I've > created > >>> https://tickets.puppetlabs.com/browse/MODULES-3993 to track this, and > will > >>> get to it next week. Until then, grepping for 'validate_|is_' is > probably a > >>> good first approximation of everything you'll need to address. > >>> > >>> > >>> Cheers, David > >> > >> -- > >> 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 [email protected]. > >> To view this discussion on the web visit > >> > https://groups.google.com/d/msgid/puppet-dev/7d10843f-4647-4e07-acea-95bd765431b4%40googlegroups.com > . > >> For more options, visit https://groups.google.com/d/optout. > > > > -- > > You received this message because you are subscribed to a topic in the > > Google Groups "Puppet Developers" group. > > To unsubscribe from this topic, visit > > https://groups.google.com/d/topic/puppet-dev/ruPhY0Oks6A/unsubscribe. > > To unsubscribe from this group and all its topics, send an email to > > [email protected]. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/puppet-dev/CAAAzDLcgrZv1BusOWm_UjVpAdDdMKwGULUguHkcC61RxAo7sGQ%40mail.gmail.com > . > > > > For more options, visit https://groups.google.com/d/optout. > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/CAFsb3b7jm371wsyS6oNBPUikz738hRp9Fj908DknnLR9nGQE%2Bw%40mail.gmail.com > . > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAAAzDLdG3ap00sR_aDX8P9rrPmyaha4gQer-8%3Dudk1bgiKGQHg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
