Something interesting I noticed while looking into this is that when xenial images are booted without "net.ifnames=0" the /var/lib/cloud/instance/ directory is not populated. Even if no datasource is provided for the image it should still create a blank cloud-config.txt and the directory structure in /var/lib/cloud/ should be set up, so I think that there is a bug somewhere else in cloud-init causing this. I think there is a good chance that this is what's triggering the issue with cc_ssh_authkey_fingerprints we're seeing here, but I am not sure how yet. I want to try to figure out why this is happening though, because in some conditions, like in curtin vmtests XenialTestNetwork everything is working correctly.
The issue with /var/lib/cloud/instance/ seems to occur both with current cloud-init and with cloud-init at revision 1188, so it is not linked to the new networking code.
Something interesting I noticed while looking into this is that when xenial images are booted without "net.ifnames=0" the /var/lib/ cloud/instance/ directory is not populated. Even if no datasource is provided for the image it should still create a blank cloud-config.txt and the directory structure in /var/lib/cloud/ should be set up, so I think that there is a bug somewhere else in cloud-init causing this. I think there is a good chance that this is what's triggering the issue with cc_ssh_ authkey_ fingerprints we're seeing here, but I am not sure how yet. I want to try to figure out why this is happening though, because in some conditions, like in curtin vmtests XenialTestNetwork everything is working correctly.
The issue with /var/lib/ cloud/instance/ seems to occur both with current cloud-init and with cloud-init at revision 1188, so it is not linked to the new networking code.