Setting node name in chef to hostname

Bug #1912437 reported by Alex
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cloud-init
Expired
Wishlist
Unassigned

Bug Description

We are using auto-install to PXE boot a number of ubuntu 20.04 hosts. These hosts are physical servers. The hostname is set via DHCP, however in the auto-install configuration file we set the identity to "localhost".

We are also trying to boot strap these servers with chef. For this we are using the user-data section in auto-install to invoke the chef module of cloud-init on first boot. This kinda works, but all the hosts which register with our chef server in this way report with a name of : iid-datasource-none

The only way we have found so far around this problem was to not accept the license in the chef module and to invoke a chef-client run via the run-cmd module as follows.

    runcmd:
      - knife ssl fetch -c /etc/chef/client.rb
      - knife ssl check -c /etc/chef/client.rb
      - chef-client -N `hostname -f` --chef-license accept
      - rm /etc/chef/validation.pem

This is not a very nice approach and it would be much better to have this option supported in the node_name attribute from the chef module or maybe add a separate flag to the module to use the systems hostname rather than the identity or the hostname (localhost) cloud-init thinks we are using.

Hopefully there is another way around this which I have missed so far.

Tags: chef
Revision history for this message
Alex (scahartner) wrote :
Alex (scahartner)
tags: added: chef
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

Hmm this is partly a consequence of switching subiquity to using DataSourceNone to configure the installed system. I'm not sure it can be fixed without cloud-init changes unfortunately.

Revision history for this message
Alex (scahartner) wrote :

Sure. Please let me know if you require any further information from me. For now we can use the work around, but it would be nice to get a better solution into cloud-init.

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

Oh I see you filed this against cloud-init already :-)

Changing DataSourceNone.get_instance_id to look for self.metadata['instance-id'] and subiquity to put something more meaningful there than a uuid might work. Although you might still need to sed it to the dhcp-assigned hostname in a late-command or something, I'm not sure that would be a great default behaviour.

Revision history for this message
Alex (scahartner) wrote :

ideally what I am looking for is for an option to query the hostname set via the DHCP option and to use that for the chef node_name.

This would allow me to centrally map the name to a specific MAC address using DHCP and use a common auto-install / cloud-init configuration for all my hosts

Revision history for this message
Dan Watkins (oddbloke) wrote :

Hey Alex, thanks for the bug report! Unfortunately, I don't think we support what you want to do at the moment. The specific lines of code in question are (https://github.com/canonical/cloud-init/blob/1527efa740ce7e66d9506ea62b0b8010d71a4104/cloudinit/config/cc_chef.py#L391-L392):

        'node_name': util.get_cfg_option_str(chef_cfg, 'node_name',
                                             default=iid),

where iid is set to `str(cloud.datasource.get_instance_id())`.

As Michael has correctly identified, this results in all of your nodes using "iid-datasource-none" because DataSourceNone always uses that as its instance ID (https://github.com/canonical/cloud-init/blob/1527efa740ce7e66d9506ea62b0b8010d71a4104/cloudinit/sources/DataSourceNone.py#L32-L33):

    def get_instance_id(self):
        return 'iid-datasource-none'

I think I agree that the two paths forward are the ones identified by each of you: either hook up instance IDs in subiquity and DataSourceNone such that each system at least has a unique instance ID internal to cloud-init, or introduce support for dynamic determination of node names into cc_chef.

Arguably we should do the former regardless, but it's not clear to me that that would fully address your issue, so I'd lean towards the latter in this case.

Do you have any thoughts on what this configuration interface could look like? My two thoughts: (a) we shouldn't support arbitrary command execution for the determination: that introduces a lot more validation, without a clear requirement for it as yet; and (b) I don't think we should overload `node_name` for this: we can add configuration options, so using magic string values isn't necessary.

Thanks!

Dan

Changed in cloud-init:
status: New → Triaged
importance: Undecided → Wishlist
Revision history for this message
Alex (scahartner) wrote :

My thoughts are that from a chef perspective using the hostname makes a lot of sense. Also the PXE process facilitates this very elegantly by linking the hostname to a specific MAC address. So we have all the host specific configuration inside the dhcpd.conf file and all the other elements can be generic for multiple hosts. This is where I thought it would be nice to be able to use the hostname.

As far as configuration interface I was hoping for a simple flag:

infer_nodename_from_hostname: true/false

Which if enabled would simply query the actual set hostname. Also if this option is enabled the value of node_name would be ignored.

Revision history for this message
James Falcon (falcojr) wrote :
Changed in cloud-init:
status: Triaged → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.