no parameter named 'release'

[SirDice]

All versions above 3.3.3 result in a puppet error: 2019-06-11T14:11:23.283+02:00 ERROR [qtp2018977016-2103763] [puppetserver] Puppet Server Error: no parameter named 'release' (file:/etc/puppetlabs/code/environments/dev_mytest/forge_modules/subscription_manager/manifests/config.pp, line: 70) on Rhsm_register[server1.example.com] (file: /etc/puppetlabs/code/environments/dev_mytest/forge_modules/subscription_manager/manifests/config.pp, line: 70) on node server2.example.com

I assume I'm doing something wrong but I just cannot find where.

Module is used in a custom bit of code but basically follows the example from the README: class { 'subscription_manager': server_hostname => $server, org => $::organization, activationkey => $real_activation_key, autosubscribe => $autosubscribe, servicelevel => 'standard', force => $force_registration, config_hash => { server_prefix => '/rhsm', rhsm_baseurl => "https://${server}/pulp/repos", rhsm_repo_ca_cert => '%(ca_cert_dir)s/katello-server-ca.pem', }, } Same code works fine on 3.3.3 but fails with unknown parameter 'release' on 5.0.0, 5.1.0, 5.1.1 and 5.2.0.

[waveclaw]

The parameter release is one of the automatically populated fields on line 29 or line 45 in subscription_manager/manifests/config.pp.

This is a potential sticky OS version to override automatic detection. The value can be empty or null.

The parameter is created and documented on line 90 in subscription_manager/lib/puppet/type/rhsm_register.pp.

This type has documentation. On your system does puppet describe resource rhsm_register display the register parameter?

Is your puppetserver process able to locate and use the files in the module correctly? You should see the rhsm_register type in /opt/puppetlabs/puppet/lib after a plugin-sync on an agent node.

[SirDice]

Sorry for the late reply, got snowed under with other priorities and promptly forgot I had created this issue.

This is a potential sticky OS version to override automatic detection. The value can be empty or null.

I understand its purpose. We sometimes have to support N-1 OS versions so this could be really useful for us.

The parameter is created and documented on line 90 in subscription_manager/lib/puppet/type/rhsm_register.pp.

I've written a few custom resources myself so this was the first file I checked, it's clearly defined there which is why I don't understand the error.

This type has documentation. On your system does puppet describe resource rhsm_register display the register parameter?

It does, yes.

Is your puppetserver process able to locate and use the files in the module correctly? You should see the rhsm_register type in /opt/puppetlabs/puppet/lib after a plugin-sync on an agent node.

I assume you mean /opt/puppetlabs/puppet/cache/lib? Then yes, it's there.

As far as I've been able to find out everything is there, right where it should be. But I still get the "no parameter named 'release'" error.

I forgot to mention the puppet version we use, it might be relevant, server is currently running puppetserver 6.4.0 with puppet 6.5.0. 98% of our client machines are running puppet 6.4.0, a few (including the test machines I used) are 6.5.0. And we have a handful still running puppet agent 5.5.0.

[evelynmitchell]

Would this be related to Environment bleed? https://tickets.puppetlabs.com/browse/SERVER-94 In looking around, restarting the puppetserver resolved similar issues.

[SirDice]

Would this be related to Environment bleed?

That is actually a good question. Something like this might be happening. I was testing the new version of the module in a separate environment while the 'production' environment still has the old version of the code (without the release parameter).

I'm going to set this up on a test server with only one environment to rule out any interference from other environments.

Thanks for the suggestion!

[waveclaw]

@SirDice any update on the test? I would like to know if I have to refactor for a possible parameter collision with the word 'release' that Puppet Labs / Puppet.com may in the future hijack for their own use.

[SirDice]

I did the tests and the error is gone! So it does indeed look like it was caused by environment bleed. That was new for me, I had never encountered something like it.

I updated the module on our test environment, made sure there was only one environment, restarted puppetserver just to be sure everything was as 'clean' as I could make it. And now the error is gone.

Big thanks to @evelynmitchell for pointing me to it.

Just for information, we're currently running puppetserver 6.5.0 with puppet 6.8.1.