Comment 14 for bug 1991261

In response to holmanb:

> Can you please elaborate on how you see the name on the network?
>
> Are you seeing this name by running `hostname`? Or some other
> method?

hostname returns miss-piggy (as expected), but the DHCP server
received "ubuntu" as the client id, and hence other machines see the
Pi as "ubuntu". This is different from prior releases where the Pi
would show up as "miss-piggy" to other machines (presumably, and this
is just speculation on my part, because the hostname was set "earlier"
before DHCP kicked off?).

In response to chad.smith:

> If the hostname were set in init-local timeframe, it would be
> correctly configured before the first DHCP client request goes out
> on the network.

> To have hostname set in init-local timeframe before initial network
> DHCP request, that data needs to be in meta-data as the
> `local-hostname` key instead of in user-data as the `hostname`
> config because your nocloud datasource is configured to run in
> init-network due to `dsmode: net` in meta-data.

Well, taking a look at the set-hostname module reference in the
cloud-init documentation [1]:

"This module *will run in the init-local stage* before networking is
configured if the hostname is set by metadata *or user data* on the
local system." (emphasis added)

[1]: https://cloudinit.readthedocs.io/en/latest/topics/modules.html#set-hostname

> I believe this behavior is the same on 22.2 as 22.3 for these
> settings, so I'm not sure how that managed to not cause the same
> problems on 22.2.

I can't be absolutely certain about the versions but I can say that
the jammy .1 and kinetic beta images reliably behave differently. I
flashed both several times yesterday and the jammy images happily DHCP
their expected hostname each time, while the kinetic images don't.

> When I look at the metadata in your attached logs I see:
>
> "meta_data": {
> "dsmode": "net",
> "instance-id": "nocloud",
> "instance_id": "cloud-image"
> }
[snip]
> 2. Set dsmode to "local" which would process all known user-data
> (your #cloud-config\nhostname: ) during init-local timeframe.

Ohhhh... now that's interesting! Why is dsmode "net". That should
almost certainly be "local" (for instance we have a 99-fake_cloud.cfg
in /etc/cloud/cloud.cfg.d that disables all data-sources except
nocloud, and redirects its seed to the partition labeled
"system-boot", which happens to be the FAT partition at the start of
the image).

I shall go and check if this has changed between jammy and kinetic...
Thanks for the hints!