On Mon, 24 Oct 2016 at 09:53 Alex Schultz <aschu...@redhat.com> wrote:
> On Mon, Oct 24, 2016 at 10:40 AM, Erik Dalén > <erik.gustav.da...@gmail.com> wrote: > > > > > > On Mon, 24 Oct 2016 at 09:32 <aschu...@redhat.com> 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, asch...@redhat.com > >>> 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 puppet-dev+unsubscr...@googlegroups.com. > >> 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 > > puppet-dev+unsubscr...@googlegroups.com. > > 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 puppet-dev+unsubscr...@googlegroups.com. > 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 puppet-dev+unsubscr...@googlegroups.com. 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.
