Thanks for the work here and answering the questions we have above.
I think I see the problem here:
`hostname: miss-piggy` is only triggering in cloud-init's the init-network stage because it is in user-data and not meta-data. User-data is only processed and acted upon by cloud-init once we hit the "init-network" and the network is already configured and brought up by systemd-network or it's ilk. Because network is already by the time cloud-init sets the hostname, the initial DHCP request on eth0 with the host-name option already leaked 'ubuntu' to your DDNS setup.
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.
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.
When I look at the metadata in your attached logs I see:
Minimally I think you can drop that "instance_id": "cloud-image" directive unless you have other uses for it as cloud-init only pays attention to "instance-id" (note the hyphen not underscore).
If we have control over that config-disk meta-data, and you know you need setting of hostname before initial DHCP request there are two options:
1. provide -"local-hostname": "miss-piggy" in meta-data not #cloud-config user-data
Dave,
Thanks for the work here and answering the questions we have above.
I think I see the problem here:
`hostname: miss-piggy` is only triggering in cloud-init's the init-network stage because it is in user-data and not meta-data. User-data is only processed and acted upon by cloud-init once we hit the "init-network" and the network is already configured and brought up by systemd-network or it's ilk. Because network is already by the time cloud-init sets the hostname, the initial DHCP request on eth0 with the host-name option already leaked 'ubuntu' to your DDNS setup.
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.
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.
When I look at the metadata in your attached logs I see:
"meta_data": {
"dsmode": "net",
"instance-id": "nocloud",
"instance_id": "cloud-image"
}
Minimally I think you can drop that "instance_id": "cloud-image" directive unless you have other uses for it as cloud-init only pays attention to "instance-id" (note the hyphen not underscore).
If we have control over that config-disk meta-data, and you know you need setting of hostname before initial DHCP request there are two options:
1. provide -"local-hostname": "miss-piggy" in meta-data not #cloud-config user-data
"meta_data": { hostname" : "miss-piggy"
"dsmode": "net",
"instance-id": "nocloud",
"local-
}
-- OR --
2. Set dsmode to "local" which would process all known user-data (your #cloud- config\ nhostname: ) during init-local timeframe.
"meta_data": {
"dsmode": "local",
"instance-id": "nocloud"
}