canonical / cloud-init

Official upstream for the cloud-init: cloud instance initialization
https://cloud-init.io/
Other
2.9k stars 863 forks source link

Setting node name in chef to hostname #3832

Open ubuntu-server-builder opened 1 year ago

ubuntu-server-builder commented 1 year ago

This bug was originally filed in Launchpad as LP: #1912437

Launchpad details
affected_projects = []
assignee = None
assignee_name = None
date_closed = None
date_created = 2021-01-20T05:01:19.729344+00:00
date_fix_committed = None
date_fix_released = None
id = 1912437
importance = wishlist
is_complete = False
lp_url = https://bugs.launchpad.net/cloud-init/+bug/1912437
milestone = None
owner = scahartner
owner_name = Alex
private = False
status = triaged
submitter = scahartner
submitter_name = Alex
tags = ['chef']
duplicates = []

Launchpad user Alex(scahartner) wrote on 2021-01-20T05:01:19.729344+00:00

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.

ubuntu-server-builder commented 1 year ago

Launchpad user Alex(scahartner) wrote on 2021-01-20T05:04:30.819098+00:00

Launchpad attachments: Auto-Install file

ubuntu-server-builder commented 1 year ago

Launchpad user Michael Hudson-Doyle(mwhudson) wrote on 2021-01-20T08:48:45.406763+00:00

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.

ubuntu-server-builder commented 1 year ago

Launchpad user Alex(scahartner) wrote on 2021-01-20T09:55:23.561359+00:00

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.

ubuntu-server-builder commented 1 year ago

Launchpad user Michael Hudson-Doyle(mwhudson) wrote on 2021-01-20T10:03:45.573631+00:00

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.

ubuntu-server-builder commented 1 year ago

Launchpad user Alex(scahartner) wrote on 2021-01-21T08:39:32.531726+00:00

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

ubuntu-server-builder commented 1 year ago

Launchpad user Dan Watkins(oddbloke) wrote on 2021-01-26T15:18:16.225568+00:00

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

ubuntu-server-builder commented 1 year ago

Launchpad user Alex(scahartner) wrote on 2021-01-26T16:37:01.358866+00:00

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.

blackknight36 commented 2 months ago

Has there been any work to support this? We have the same issue in our environment. The only workaround I have found is to set node_name to '#{`hostname`.chomp!}' which will then get evaluated by chef-client when it runs.

aciba90 commented 2 months ago

There has been no work to support this. Contributions are welcome!