The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Feature #11320

node_name_value unavailible as a fact

Added by Ramin K about 3 years ago. Updated over 2 years ago.

Status:ClosedStart date:12/09/2011
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:library
Target version:-
Keywords: Affected Facter version:
Branch:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This issue is currently not available for export. If you are experiencing the issue described below, please file a new ticket in JIRA. Once a new ticket has been created, please add a link to it that points back to this Redmine ticket.


Description

I’m not sure this is a bug so I’m calling it a feature until someone says otherwise. What I’m trying to do is divorce certname from fqdn and the name of the node from either of those. Comments in Issue #2128 could be interpreted to say that this is an acceptable and valid use case.

Client is 2.7.6 with Facter 1.6.2. The master is 2.7.6. I have this set in my puppet.conf on the client. No changes to the standard config on the master for node names.

[agent]
certname = 007f0101
node_name_value = precise01.stage.aws

The above works and matches my regex for Ubuntu Precise testing. However I can not find any way to use the value of node_name_value as a fact.

I could write a custom fact, but it seems like I should be able to access node_name in some way for manifests outside of it’s mapping to certname, clientcert, hostname, or fqdn. Also I’m not sure that solves the problem since I’d end up setting node_name_fact rather than using node_name_value.

History

#1 Updated by Anonymous about 3 years ago

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

Nigel, seems like a reasonable feature request, and something we should make default. OTOH, it isn’t actually a fact level thing, unless we start adding custom facts inside the Puppet process, which is an architecture change (around the layers of responsibility) as far as I know. Can you make a final call on this, please.

#2 Updated by Ramin K about 3 years ago

If you do decide to go forward, it could work along the same lines as certname/clientcert which is solving a similar problem. ::clientnode?

#3 Updated by James Turnbull about 3 years ago

We actually have a number of custom facts set in the Puppet process now so this wouldn’t be a big change.

#4 Updated by Ramin K about 3 years ago

The comment by James got me thinking so I did some testing. I think Puppet.settings[:node_name_value] should always exist and be correct, but I couldn’t say for certain. Adding the additional fact didn’t seem to interfere with existing facts in my limited testing and it was set correctly when defaulting to certname or fdqn. I think this the right method/place to handle it rather than in facter as it’s like the rest of the internal facts in that it comes from puppet.conf.

diff --git a/lib/puppet/node/facts.rb b/lib/puppet/node/facts.rb
index 8d0a034..a8441b8 100755
--- a/lib/puppet/node/facts.rb
+++ b/lib/puppet/node/facts.rb
@@ -27,6 +27,7 @@ class Puppet::Node::Facts
 
   def add_local_facts
     values["clientcert"] = Puppet.settings[:certname]
+    values["clientnode"] = Puppet.settings[:node_name_value]
     values["clientversion"] = Puppet.version.to_s
     values["environment"] ||= Puppet.settings[:environment]
   end

#5 Updated by Nigel Kersten about 3 years ago

  • Status changed from Needs Decision to Accepted
  • Assignee deleted (Nigel Kersten)

Accepted, but is it really the case that these things are “facts” ?

#6 Updated by James Turnbull about 3 years ago

  • Category set to library

They totally are! :) And are treated like that through the core.

#7 Updated by Ken Barber almost 3 years ago

  • Target version set to 186

#8 Updated by Anonymous almost 3 years ago

  • Target version deleted (186)

#9 Updated by Ken Barber over 2 years ago

Does this belong in the facter project? Weither you’re adding facts in Puppet – or just adding variables into the scope – I don’t think the change occurs in Facter in this case.

We do however have an example of a fact created outside of Puppet that taps Puppet information:

https://github.com/puppetlabs/puppetlabs-stdlib/blob/master/lib/facter/puppet_vardir.rb

So it ultimately depends on what you want here. We could theoretically do it this way – and return what is effectively all puppet configuration in facter – which could then be used outside facter?

#10 Updated by Jeff McCune over 2 years ago

  • Status changed from Accepted to Needs More Information
  • Assignee set to Ramin K

The above works and matches my regex for Ubuntu Precise testing. However I can not find any way to use the value of node_name_value as a fact.

Hey, so I just saw this ticket.

Ramin, if you want to set the node’s name based on the value of a fact I think you should use the node_name_fact setting. The node_name_value setting is meant to be hard coded in puppet.conf where as the node_name_fact setting is meant to specify a facter fact that will provide a value for the node name.

From the output of puppet agent --genconfig:

...
    # The explicit value used for the node name for all requests the agent
    # makes to the master. WARNING: This setting is mutually exclusive with
    # node_name_fact.  Changing this setting also requires changes to the default
    # auth.conf configuration on the Puppet Master.  Please see
    # http://links.puppetlabs.com/node_name_value for more information.
    # The default value is '$certname'.
    node_name_value = maynard.local
...
    # The fact name used to determine the node name used for all requests the agent
    # makes to the master. WARNING: This setting is mutually exclusive with
    # node_name_value.  Changing this setting also requires changes to the default
    # auth.conf configuration on the Puppet Master.  Please see
    # http://links.puppetlabs.com/node_name_fact for more information.
    # The default value is ''.
    # node_name_fact = 

With this information, could you let me know if this is still a bug?

#11 Updated by Jeff McCune over 2 years ago

  • Status changed from Needs More Information to Closed
  • Assignee deleted (Ramin K)

Closing for the time being. Please re-open this ticket if node_name_fact does not accomplish the goal.

I believe this is not a bug and the node_name_fact setting in Puppet accomplishes the goal of, “What I’m trying to do is divorce certname from fqdn and the name of the node from either of those.”

-Jeff

Also available in: Atom PDF