Issue #2128 has been updated by Jeff McCune.
Nick Lewis wrote:
> Being able to specify the node name used for classification on the master via
> arbitrary facts won't address the deeper concurrency issues surrounding
> having multiple nodes with the same name check in at the same time. You
> should still have unique node names for each host that checks in (IE:
> ec2_apache_${uuid}).
So to be clear. The issue we face today is that a fact _can_ be used for
classification that is not the node name. This is the fqdn fact. This is
problem because we're only bothering to do classification using this fact and
everything else in the system still uses the node name.
e.g. the exec node terminus, reporting, the facts terminus, all still use node
name.
This ticket is more than just classification. Everything needs to support the
identification of a node using an arbitrary fact, not _just_ classification.
In this situation, I don't understand the statement, "You should still have
unique node names for each host that checks in (IE: ec2_apache_${uuid})."
because the fact itself becomes the unique node name.
----------------------------------------
Feature #2128: Allow arbitrary fact as node_name identifier
https://projects.puppetlabs.com/issues/2128
Author: Bill Bartlett
Status: Accepted
Priority: High
Assignee:
Category: node
Target version: 2.6.x
Affected Puppet version: 0.24.7
Keywords:
Branch:
Currently, the only fact available as a node_name identifier is the hostname.
I would like to have the capability of having any fact be the node_name
identifier.
Use Case:
The reason this discussion came about is EC2. When an EC2 node is brought up,
the hostname is not known. If we were to have a large, auto-scaling
infrastructure, it is currently very difficult (impossible?) to automate
bringing these EC2 nodes into puppet.
One possible solution is to allow any fact as a node_name, and then for each
particular EC2 instance type that one would need scaling (apache, memcache,
mysql all come to mind among many others), the AMI would be customized with a
custom fact. An example could be a fact called "hostclass" that would then be
set to "ec2_apache", "ec2_memcache", or similar. This allows the auto-created
machine, which we would otherwise be unable to differentiate from any other EC2
node, access to puppet in an automated way.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
