Puppet: System Administration Automated

Support

Ticket #682 (assigned enhancement)

Opened 1 year ago

Last modified 7 months ago

Should be able to override noop when set in a type

Reported by: whaymand Assigned to: luke (accepted)
Priority: normal Milestone: elmo
Component: RAL Version:
Severity: normal Keywords: noop tag
Cc: Triage Stage: Accepted
Attached Patches: None Complexity: Unknown

Description (Last modified by luke)

I'm thinking about a configuration class that, amongst other things execs out to a 'dangerous' configuration script. I'd like to make this a noop by default, so the operator has to try a bit harder to invoke it. So I thought about doing something like:

class blah {
    exec { danger:
        noop => true,
        tag => hitme,
        command => "might_break_it",
        path => "/bin:/usr/bin:/usr/local/bin",
        logoutput => true
    }
}

And fire up puppetd with

puppetd -o --tags hitme

Unfortunately it doesn't fire the script... Whilst I see from an earlier post in puppet-users there you can supply --no-noop to puppetd, it makes no difference. I presume this getoptism only works if the noop you're using has been put in puppet.conf, not in the type.

This enhancement request is to create a way to override the "noop => true".

Change History

07/04/07 21:21:01 changed by luke

  • status changed from new to assigned.
  • stage changed from Unreviewed to Accepted.
  • description changed.
  • milestone set to beaker.

The real problem here is that --no-noop should always disable noop, which it doesn't appear to do. This should be a simple fix.

Also, fixing the markup.

07/05/07 00:38:19 changed by luke

Unfortunately, fixing this changes the semantics of --no-noop. Currently, "noop" is a boolean, and if it's false then the resource value is used but if it's true, then no work is done regardless of the resource value. We need a third value that means evaluate a resource even if it's noop value is true.

Really, I expect this to have "true" stay the same, "false" mean "always evaluate, regardless of the resource setting", and then come up with a new term meaning "use whatever is set on the resource".

Note that the nature of the Config stuff means that when this happens, :noop will no longer be boolean, which means will need to add some getopt hooks to make --noop and --no-noop still function equivalently.

07/18/07 19:35:21 changed by luke

  • milestone changed from beaker to elmo.

Because of the surprising amount of complexity, and the fact that this would break backward-compatibility, I'm delaying this.

11/24/07 04:15:23 changed by luke

  • type changed from defect to enhancement.

04/24/08 07:51:25 changed by luke

  • component changed from library to unknown.

04/28/08 16:39:12 changed by luke

  • component changed from unknown to RAL.