The Puppet Labs Issue Tracker has Moved:

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using See the following page for information on filing tickets with JIRA:

Bug #6847

Cannot read client $noop setting

Added by John Crenshaw about 5 years ago. Updated over 2 years ago.

Status:ClosedStart date:03/25/2011
Priority:NormalDue date:
Assignee:-% Done:


Target version:3.3.0
Affected Puppet version: Branch:

We've Moved!

Ticket tracking is now hosted in JIRA:


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.

Related issues

Related to Puppet - Bug #6526: $noop metaparameter no longer works Rejected 03/01/2011


#1 Updated by Ben Hughes about 5 years ago

  • Status changed from Unreviewed to Needs Decision
  • Assignee set to Nigel Kersten

#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.

#3 Updated by Nigel Kersten almost 5 years ago

Is #6525 really the correct bug? It doesn’t seem to be relevant.

#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…

#5 Updated by Steve Shipway over 4 years ago

Any update on this? We would really find this functionality useful (being able to read $noop state from manifest or user function). Thanks

#6 Updated by Nigel Kersten almost 4 years ago

  • Assignee changed from Nigel Kersten to eric sorenson

#7 Updated by Mathieu Parent almost 3 years ago

Proposed fix:

#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 (eric sorenson)
  • Target version set to 3.3.0

summary: merged into master in 4ab5271; this should be released in 3.3.0.

#9 Updated by Adrien Thebo almost 3 years ago

  • Branch set to

#10 Updated by Anonymous over 2 years ago

  • Status changed from Merged - Pending Release to Closed

Released in 3.3.0

#11 Updated by Anonymous over 2 years ago

Released in 3.3.0

Also available in: Atom PDF