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:
puppet config print and --configprint disagree
|Affected Puppet version:||Branch:||https://github.com/puppetlabs/puppet/pull/1143|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
thinky:puppet:% puppet master --configprint ssldir <3.x> /etc/puppet/ssl thinky:puppet:% puppet config print ssldir --mode master <3.x> /home/patrick/.puppet/ssl
#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
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
I wonder if any face manages to execute in a mode other than
#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
: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
--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
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
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
Application.class.run:mode, 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
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
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
--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
doc applications use of
--mode is still bad, but that is a separate issue).
#7 Updated by eric sorenson over 3 years ago
- Status changed from Accepted to Merged - Pending Release
Merged in d41ac79 —
email@example.com ~/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
#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?