The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:
Cannot read client $noop setting
|Affected Puppet version:||Branch:||https://github.com/puppetlabs/puppet/pull/1783|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
Discovered this when trying to work around the error that caused me to discover #6846. Basically, I needed to be able to detect the “noop” intention to prevent the dry run from erroring out due to some complex dependencies. It looks like per #6525 the $noop variable is no longer available in any form, even for reading. I can understand why changing it at runtime would not be something you want to support, but readonly access doesn’t violate the need in #6525 and is pretty important to allow workarounds for situations like this, where not all interdependencies are fully visible to puppet (and therefore the developer is responsible to enforce the noop).
For now, I’ve worked around this by adding FACTER_noop=1 to my command line. It’s clunky and redundant, but at least it lets me check my code.
#2 Updated by Steve Shipway almost 5 years ago
This functionality would be of great use to us as well. We have integrated Puppet with the SecretServer software to automatically maintain root passwords (changing after 60 days and update in SecretServer) but the ruby code to update SecretServer is still run when in noop mode, even though the Exec to actually change the password is not! We need some way to detect noop mode from within the manifest.
#4 Updated by Steve Shipway over 4 years ago
I think the original poster meant bug #6526 ( $noop cannot be assigned ). This bug was rejected because being able to assign to $noop during a manifest would do all sorts of horrible things.
However this problem is more being unable to READ the $noop variable , so that you can make manifests behave differently in noop mode — specifically (in my case) allowing a custom ruby function to suppress actions when in noop mode. I think this functionality (read-only $noop) should be fairly simple to achieve — there may even be a way to do it in a custom function already, though I wouldnt know what it is…
#8 Updated by Adrien Thebo almost 3 years ago
- Subject changed from Cannot read $noop to Cannot read client $noop setting
- Category set to settings
- Status changed from Needs Decision to Merged - Pending Release
- Assignee deleted (
- Target version set to 3.3.0
summary: merged into master in 4ab5271; this should be released in 3.3.0.