Calls to `Deprecation` function cause catalog compilation to fail if `strict` setting is set to `error`

[alexjfisher]

In stdlib 9.0 many functions were namespaced and non-namespaced deprecated shims were introduced to maintain compatibility with modules that haven't yet switched over to using the namespaced versions.

This largely works as intended, but (originally in #1365) it's been noted that the deprecation function will actually fail a catalog compile when strict is set to error, and that this is also the default in the upcoming Puppet 8.

This makes it very difficult for users to upgrade to stdlib 9 unless they're prepared to turn the strict setting back to off or warning (and there are many other good reasons for setting strict to error). Since lots of modules are now also being updated to use the namespaced versions (requiring stdlib 9.0), upgrading a single affected component module now means having to upgrade all modules that use stdlib functions.

Possible solutions include:

• Still leaving the shims documented as deprecated, but removing the calls to the deprecation function
• Adjusting deprecation so that it never raises an error

(This issue replaces #1365 where 2 separate issues were being discussed)

[alexjfisher]

I'm thinking add an extra optional parameter to deprecation that controls whether the strict puppet setting is used or not. Can default to true but be called with false in all the shims in at least this module.

[robertc99]

One minor issue. Even if this is adjusted to produce warnings not errors, upgrading to stdlib9 will be stuck with lots of ugly warnings from all the stdlib using modules which havent released a new version yet. Which could take a while.

One option would be to do a phased rollout.

For now, document the functions as deprecated, but dont produce warnings.
In say 6 months, adjust so the functions produce deprecated warnings.
In a year, adjust to follow the strict setting. People can still turn off strict, if they need to use some (hopefully unusual ) module that hasnt been updated.

[alexjfisher]

I think I'm ok with spamming warnings by default. If they are causing you too much noise, there appear to already be two ways you could silence them. You can use https://www.puppet.com/docs/puppet/7/configuration.html#disable-warnings to disable all deprecation warnings, or apparently also set the environment variable STDLIB_LOG_DEPRECATIONS to the 'false' to disable just stdlib deprecation function generated warnings. (Looks like this was designed with being able to turn off warnings during testing, but I can't see why you couldn't also set this up on your puppetserver)

[bastelfreak]

My proposal from the Vox Pupuli meeting: Don't call deprecation, instead create a notify resource with warn as loglevel and maybe in addition warn() to log to the puppetserver as well.

[jhoblitt]

This is really ugly. As is, I doubt the community will ever upgrade to stdlib 9 because modules and their recursive deps which use stdlib function will need to switch to the namespaced version simultaneously. There absolutely needs to be a way to do an incremental transition. A few possibilities are:

• A new language construct to specifically handle converting from non-namespaced to namespaced functions one module at a time...
• puppet 8 reverts the strict default back to warn
• stdlib removes the deprecation warning from the non-namespaced functions for the entire 9.x series
• a new 8.x release is made which includes namespaced versions of the functions but without the deprecation warnings

[jhoblitt]

My preference would be for 9.x to remove the deprecation warnings and plan to bring them back in 10.x.

/CC @smortex

[robertc99]

I have to agree. It would be best if there was a version where both the name spaced and non versions worked without warnings or errors, so people could upgrade as needed without issues.

[jhoblitt]

I am unfortunately having to pin .fixture.yml versions which had been intentionally left free floating as modules such as puppetlabs/mysql are updated to use stdlib 9.x namespace functions. The more people start to pin versions of test fixtures due to stdlib 9.x namespaced functions the harder it is going to be for the everyone else in the community to upgrade.

[pmcmaw]

Hey everyone! Im just dropping a message to let you all know, we aren't ignoring you all and we are chatting in the background to come up with a reasonable change to resolve this for everyone. 👍

[bastelfreak]

a recommendation I posted on slack: cherry-pick the new namespaced functions into a 8.7 release. That would enable people to migrate to the name functions without a major version bump.

[chelnak]

My proposal from the Vox Pupuli meeting: Don't call deprecation, instead create a notify resource with warn as loglevel and maybe in addition warn() to log to the puppetserver as well.

@bastelfreak I wonder if this may be the least impactful approach? We can then, as suggested above, re-add the deprecation function in a phased manner.

With regards to your post above. I'm a fan of moving forward. Maintaining a separate 8x track could end up getting complicated.