Feature #2807

Agent settings should be available within the parser

Added by Mario Verbelen over 2 years ago. Updated 18 days ago.

Status:Accepted Start date:11/12/2009
Priority:High Due date:
Assignee:- % Done:

0%

Category:language
Target version:3.x
Affected Puppet version:0.25.1 Branch:
Keywords:
Votes: 3

Description

It should be straightforward to make all of the Puppet settings available as variables within the language, and this has been asked for many times.

History

Updated by James Turnbull over 2 years ago

  • Category set to language
  • Status changed from Unreviewed to Needs Decision
  • Assignee set to Luke Kanies
  • Target version set to 2.6.0
  • Affected Puppet version changed from 0.25.2 to 0.25.1

Updated by Luke Kanies over 2 years ago

  • Subject changed from certname as a variable (if certname is different from hostname) to Settings should be available within the parser
  • Assignee deleted (Luke Kanies)

It seems more reasonable to just provide access to all of the settings, since that’s commonly requested. I can’t seem to find it as a ticket, though, so I’m going to modify this one.

Updated by Markus Roberts over 2 years ago

  • Assignee set to Markus Roberts

Updated by Markus Roberts over 2 years ago

  • Status changed from Needs Decision to Accepted

I’m removing the “needs design decision” but want to note that abuse of such a feature (e.g. to radically change behavior depending on the port, or similar games) could make debugging a configuration much more difficult.

Updated by Mario Verbelen over 2 years ago

I can understand a risk of abuse if you display all of you configuration,

I don’t want to include the ldap passwd(as example) On a installation I have external admins that can work on puppet via svn so they can commit there own templates and resolve that passwd

But the certname is use full and maybe some other variables as well

Updated by Jesse Wolfe about 2 years ago

  • Target version changed from 2.6.0 to 52

Updated by Jesse Wolfe almost 2 years ago

  • Target version changed from 52 to 2.6.0

Updated by James Turnbull almost 2 years ago

Code here:

diff --git a/lib/puppet/parser/compiler.rb b/lib/puppet/parser/compiler.rb
index 4357a3a..0a9d080 100644
--- a/lib/puppet/parser/compiler.rb
+++ b/lib/puppet/parser/compiler.rb
@@ -97,6 +97,7 @@ class Puppet::Parser::Compiler
     def compile
         # Set the client's parameters into the top scope.
         set_node_parameters()
+        create_settings_scope
 
         evaluate_main()
 
@@ -447,7 +448,7 @@ class Puppet::Parser::Compiler
         @catalog.version = known_resource_types.version
 
         # Create our initial scope and a resource that will evaluate main.
-        @topscope = Puppet::Parser::Scope.new(:compiler => self, :source => 'implicit')
+        @topscope = Puppet::Parser::Scope.new(:compiler => self)
 
         @main_stage_resource = Puppet::Parser::Resource.new("stage", :main, :scope => @topscope)
         @catalog.add_resource(@main_stage_resource)
@@ -470,6 +471,25 @@ class Puppet::Parser::Compiler
         catalog.server_version = node.parameters["serverversion"]
     end
 
+    def create_settings_scope
+        unless settings_type = environment.known_resource_types.hostclass("settings")
+            settings_type = Puppet::Resource::Type.new :hostclass, "settings"
+            environment.known_resource_types.add(settings_type)
+        end
+
+        settings_resource = Puppet::Parser::Resource.new("class", "settings", :scope => @topscope)
+        settings_type.evaluate_code(settings_resource)
+
+        @catalog.add_resource(settings_resource)
+
+        scope = @topscope.class_scope(settings_type)
+
+        Puppet.settings.each do |name, setting|
+            next if name.to_s == "name"
+            scope.setvar name.to_s, environment[name]
+        end
+    end
+
     # Return an array of all of the unevaluated resources.  These will be definitions,
     # which need to get evaluated into native resources.
     def unevaluated_resources

Updated by Markus Roberts almost 2 years ago

Fixed in commit:62dbae53f89e8d9597081c7b7c0a20b419e4737a

Updated by Markus Roberts almost 2 years ago

  • Status changed from Accepted to Closed

Updated by Alan Barrett almost 2 years ago

Workaround for those of us still using puppet-0.25:

$confdir = inline_template("<%= Puppet.settings[:confdir] %>")

Updated by Dan Bode almost 2 years ago

  • Status changed from Closed to Re-opened
  • Assignee deleted (Markus Roberts)
  • Target version deleted (2.6.0)

After looking into this feature, I want to reopen the ticket for discussion:

The implementation did not meet my expectations, but its possible that my expectations are incorrect.

I expected $settings:: to return config settings for the client, but it actually returns the servers config settings.

I ran the following tests:

node default { notify {“certname is: ${settings::certname}”:} notify {“noop is: ${settings::noop}”:} }

puppetd -t --certname blah --noop
notice: /Stage[main]//Node[default]/Notify[certname is: puppetmaster]/message: is absent, should be certname is: puppetmaster (noop)
notice: /Stage[main]//Node[default]/Notify[noop is: false]/message: is absent, should be noop is: false (noop)

Its clear base on this test that neither of these values are coming from the client’s config. I verified that they were in fact coming from the server’s config.

puppetmasterd --no-daemonize --verbose --noop
puppetd -t --certname blah
notice: certname is: puppetmaster
notice: /Stage[main]//Node[default]/Notify[certname is: puppetmaster]/message: defined 'message' as 'certname is: puppetmaster'
notice: noop is: true
notice: /Stage[main]//Node[default]/Notify[noop is: true]/message: defined 'message' as 'noop is: true'

even though this ticket was assigned to Markus, I unassigned it before I re-opened it. Mostly out of confusion.

Updated by Mario Verbelen almost 2 years ago

idd it should be return the client settings

I confirm this on puppet 2.6

Updated by James Turnbull 7 months ago

  • Status changed from Re-opened to Needs Decision
  • Assignee set to Nigel Kersten

Updated by Nigel Kersten 6 months ago

  • Subject changed from Settings should be available within the parser to Agent settings should be available within the parser
  • Status changed from Needs Decision to Accepted
  • Assignee deleted (Nigel Kersten)
  • Priority changed from Normal to High
  • Target version set to 3.x

Yeah, we need to add the agent settings.

Also available in: Atom PDF