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

puppet config print and --configprint disagree

Added by Patrick Carlisle over 3 years ago. Updated about 3 years ago.

Status:ClosedStart date:08/30/2012
Priority:NormalDue date:
Assignee:-% Done:


Target version:3.0.0
Affected Puppet version: Branch:

We've Moved!

Ticket tracking is now hosted in JIRA:


thinky:puppet:% puppet master --configprint ssldir                                                                                                                                      <3.x>
thinky:puppet:% puppet config print ssldir --mode master                                                                                                                                <3.x>

Related issues

Related to Puppet - Bug #15214: Get rid of coupling between run_mode and confdir/vardir Duplicate 06/25/2012
Related to Puppet - Refactor #13334: Improve handling of "run_mode" setting Closed 03/22/2012
Related to Puppet - Feature #2935: Settings should use 'agent' and 'server' in addition to e... Closed 12/15/2009
Related to Puppet - Bug #17554: runinterval ignored on Windows Closed


#1 Updated by Anonymous over 3 years ago

  • Status changed from Unreviewed to Accepted

#2 Updated by Henrik Lindberg over 3 years ago

Started to look into this.

The config command is a face, and relies on ´Puppet::Application::FaceBase´ to handle the ´—mode´ option. At the start of ´FaceBase´, it calls ´run_mode :agent´ which supposedly should be replaced with the wanted run mode, it later calls self.class.run_mode(arg.to_sym) where arg is the arg to --mode.

Changing the default run_mode :agent to run_mode :master has no effect.

On the surface, it looks like it is doing what the Puppet::Application::Master is doing as it starts with run_mode :master.

I wonder if any face manages to execute in a mode other than :agent ?

#3 Updated by Henrik Lindberg over 3 years ago

After some investigation: There are two (or more :) problems in play here.

Problem 1: Application defaults are setup before the FaceBase class interprets the command line option --mode. At the point it has figured out that it wants :master it is too late as the values that it will print has already interpolated the result based on some default.

Problem 2: The default value is not computed the correct way. @run_mode is a class instance variable and the Config class that is created for the config face does not inherit this class variable from FaceBase. (Such inheritance must be done manually in ruby). As a result, the run_mode that gets picked is nil, which leads to a default of the :user run mode (set in the class level run mode method defined in application.rb like this: @run_mode = Puppet::Util::RunMode[ mode_name || :user ]). Thus, neither the default in Application, nor in FaceBase gets used.

#4 Updated by Henrik Lindberg over 3 years ago

Solution “pushing handling of —mode to be global”:

There is one obvious way of fixing the problem; by making --mode a global option (or rather --runmode, as --mode clashes with the doc application which uses --mode (-m) for documentation mode (text, pdf, rdoc). Either rename doc’s mode-option, or rename the run mode option to --runmode (-r) which is more consistent than the current --mode (-r)).

A downside is that it is possible to set a stupid run mode e.g. master --mode user and vice versa.

If this solution is chosen, the actual work can be done in Settings.parse_global_options + method for the option called from Settings.handlearg.

As a consequence, the actual run mode to use would then need to be picked up from Settings. This can be done the way it is done now, but instead of picking :user as a default in, it would pick up the default from Settings. Settings in turn would naturally return :user if no mode option was used on the command line.

#5 Updated by Henrik Lindberg over 3 years ago

cigar ! So, there is already a global parameter defined with parsing and everything for the option run_mode. It is however made readonly.

By simply making it not read only, and translating the string to a symbol, the run_mode gets set as a default. The default default is still :user (defined in Settings). In addition to this, the only thing required is for the application is to use this default from Settings instead of a static :user.

This means that applications (such as Application::Master) which sets the run_mode explicitly works as before. (As will it work for any other application that did the same). All others, which relied on the default :user will now either get it from the command line option, or the :user default in Settings.

Problem solved

The option --mode can be removed from FaceBase, as can the attempt in FaceBase to set the run mode to :agent (which does not work at all anyway).

From a user perspective, what changed was the --mode changed to --run_mode. (The doc applications use of --mode is still bad, but that is a separate issue).

#6 Updated by Henrik Lindberg over 3 years ago

  • Branch set to

Added pull request with fix for review.

#7 Updated by eric sorenson over 3 years ago

  • Status changed from Accepted to Merged - Pending Release

Merged in d41ac79 —

eric@glitch.local ~/Sandbox/puppet]% git show d41ac79
commit d41ac798fb27d562745160c35525f7de59869a5b
Merge: 285ea80 f4e229e
Author: Andrew Parker 
Date:   Fri Sep 14 15:47:54 2012 -0700

    Merge branch 'ticket/3.x/16189-run_mode-not-working-for-faces' into 3.x
    * ticket/3.x/16189-run_mode-not-working-for-faces:
      (#16189) Make --run_mode a global option and not a setting

#8 Updated by Matthaus Owens over 3 years ago

  • Status changed from Merged - Pending Release to Closed
  • Affected Puppet version deleted (3.0.0-rc5)

Released in Puppet 3.0.0-rc7

#9 Updated by Daniele Sluijters about 3 years ago

This is actually just as broken on 2.7, any chance we might see a fix for that too?

#10 Updated by Anonymous about 3 years ago

Daniele Sluijters wrote:

This is actually just as broken on 2.7, any chance we might see a fix for that too?

Unfortunately not, the underlying run_mode issue exists in 2.7 and is fixed in Puppet 3 and later. Since the root problem is nested deep inside of Puppet we won’t be back porting this fix to 2.7.

Is there something blocking you from taking advantage of the fix in Puppet 3 and later?


Also available in: Atom PDF