Issue #2128 has been updated by Nick Lewis.
James Turnbull wrote: > Nick Lewis wrote: > > In the case where `node_name_value` isn't anything remotely related to the > > hostname, these don't make a lot of sense as fallbacks. In that case, the > > `strict_hostname_checking` setting can be enabled to only allow > > `node_name_value` as a valid node name. > > So this is still used for: > > lib/puppet/indirector/node/exec.rb > lib/puppet/indirector/node/ldap.rb > lib/puppet/rails/host.rb > > Should we perhaps refactor this code a little to make it a bit saner as part > of this exercise? I think in light of the node_name_value change this > violates the principal of least surprise but happy to be wrong too. :) That would be ideal, but I don't really feel comfortable doing that in 2.6.x, particularly this late into its lifetime, and with code that's a) important, and b) complex. Some of those sorts of refactors would be extremely valuable and appropriate against master, though. There are certainly places in the code that still want to assume the node's name is its certname is its hostname, and this fix really just sort of hacks around them. ---------------------------------------- Feature #2128: Allow arbitrary fact as node_name identifier https://projects.puppetlabs.com/issues/2128 Author: Bill Bartlett Status: Accepted Priority: High Assignee: Nick Lewis 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.
