Comment 5 for bug 1836733

Okay well I had seen and understood that about the instance-id in meta-data. Let's try...

I have a meta-data file with just this.

#cloud-config
#vim:syntax=yaml

instance-id: myserver-id111
local-hostname: myserver111

If I change the ISO meta-data file's instance-id and local-hostname to *002 (including the network-config IP that works prior's IP to be different) and simply reboot the VM via
shutdown -r now
it comes back but does not change the hostname or IP or anything unless you run 'cloud-init clean'

network-config looks like this for ubuntu 19.04...
#cloud-config
#vim:syntax=yaml

ethernets:
    enp0s3:
        addresses: [192.168.3.111/24]
        gateway4: 192.168.3.1
        dhcp4: false
version: 2

If I disconnect the seed.ISO and reboot it retains last settings fine.
If I 'cloud-init clean' and 'reboot' it will revert to dhcp for addresses but keep the hostname, [which I suppose is expected behavior, but I just thought I'd should add that fact].

Even though /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg
has been deleted, which would have this...
network:
  ethernets:
    enp0s3:
      dhcp4: true
  version: 2

technically with the 50-curtin-networking.cfg networking setting file destroyed maybe it should keep what it had but I guess dhcp is default.

I think maybe the cloud-init network-config should be checked if it was last first booted from it for different IP settings per boot as I imagine it should from a meta-data_url or 'net' data-source.

I will investigate eventually how cloud-init might work differently in this regard when a https://*.254 URL is present but it seems like every boot you'd need to reset the cloud-init to get different IPs at boot without just relying on a regular DHCP being hosted by default (or otherwise) on a given VPC (Virtual Private Cloud) network.