FYI, there are approximately 70 days until that puppet 3 support you mentioned ends.
On Monday, October 24, 2016, <[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. > > 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-opens >>> tack-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] > <javascript:_e(%7B%7D,'cvml','puppet-dev%[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 > <https://groups.google.com/d/msgid/puppet-dev/7d10843f-4647-4e07-acea-95bd765431b4%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Rob Nelson [email protected] -- 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/CAC76iT9Spz5we7kRiWNCJW%3Dw1W%2BdFKv6PSQO9j%3DvWefGVSU3Vw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
