Stdlib 8 to 9 Compatibility

[davidsandilands]

Stdlib 8 to 9 Compatability

So after a long consideration and seeing continued difficulties for community and customers, we want to reopen the discussions on the issues experienced here. We would like to understand the key components causing the most issues and preferred solutions

[bastelfreak]

Hi David, thanks for starting the discussion. I would like to see #1356 backported to stdlib 8. That would make a migration from 8 to 9 easier, because the old versions of tree those functions got removed in 9. That would enable us to use old and new functions in parallel and upgrade each depending module after another, instead of all at the same time.

[ekohl]

Exactly this. You can't have a smooth migration path today because of that. Ideally speaking there would be a puppetlabs-stdlib 8.7.0 (current latest is 8.6.0) that includes the namespaced functions.

Then all module authors switch to namespaces functions and raises the stdlib dependency to >= 8.7 < 10.

Now control repository maintainers can update their stdlib to 8.7.0 without any issue. They should address any deprecation warnings in their repositories (like profile modules). Once all their modules (in Puppetfile) have raised their stdlib dependency to < 10 they can safely update to stdlib 9.

What happened in practice was that you couldn't be compatible with both stdlib 8 & 9, meaning there was a hard switch. This meant there was a certain point in time where you needed to make sure all your modules were updated at the same time. If you needed a feature from a module that was stdlib 9 compatible, but still had other modules which weren't, tough luck.

This stdlib 8.7.0 release was asked by the community at the time, causing great pain. At this point, I wonder if there's still a benefit to releasing 8.7.0 because most of the ecosystem has switched over already. It will be a lot of work to retroactively change the dependencies from >= 9 < 10 to >= 8.7 < 10.

[bastelfreak]

As a module maintainer I would not update my modules to >= 8.7 < 10. But as an enterprise customer read:someone who messed it up to upgrade anything in the past years and now runs on EOL modules + puppet + OSes) I would appreciate the 8.7 release to make the upgrade easier.

[seanmil]

Agreed. As an enterprise customer, having the functions backported to 8.x would ease so much internal pain.

[Adam-Shambrook]

I think the long list of functions removed from stdlib 9.0.0 changelog adds confusion and in some cases overwhlem as to where to start. The vast majority of functions removed from stdlib were built-in to Puppet 6 under the same function name, and can be found on the respective version pages here: https://www.puppet.com/docs/puppet/8/function.html

Providing a more concise function list of deprecations can help to simply Puppet user requirements. From a quick comparison, I count only these 7 removed functions listed in the changelog are not built into Puppet:

1. is_array functionality can be achieved with Stdlib::Compat::Array
2. is_absolute_path can be achieved with Stdlib::Compat::Absolute_Path
3. stdlib 'hash' replaced by Puppet hash.new
4. has_key functionality can be achieved with the expression provided here: Remove deprecated has_key function #1319
5. 'dig44' is removed
6. 'private' is removed
7. 'type3x' is removed

[ekohl]

That's another thing that could have been done: provide an UPGRADING.md that goes over this.

is_array functionality can be achieved with Stdlib::Compat::Array

Or simply use $var =~ Array if you want to be modern. Even better: use data types on your parameters.

is_absolute_path can be achieved with Stdlib::Compat::Absolute_Path

The compat was a hack. If you're migrating, use Stdlib::Absolutepath. Again, better to use data types on your parameters than to check it in the body.