Comment 4 for bug 1810859

@Robert,

I've known that this was a potential problem since cloud-init's first creation, but I'd never seen it in practice. ds-identify makes it more likely but removing it doesn't "fix" the problem entirely either.

You describe the recreate as "Observed in a test environment with qemu and the data source on a separate virtual device.". Thats not very helpful, and not necessarily an issue. I assume that it means that ds-identify disabled cloud-init. The intent of ds-identify is to in fact identify known scenarios when cloud-init should run, and only enable cloud-init when that is the case.

I'm not particularly bothered if someone writes "cloud-init did not identify my
in-house developed EC2 clone as EC2". The response to that is either:
a.) fix your in-house clone to be a perfect clone (bug 1793590).
b.) adjust cloud-init to know about your clone, ideally as a separate
datasource (ie, Aliyun)

So ... I suggest that you have those two options also. If the platform clearly
identifies itself (possibly through dmi infornation or any other "local" path)
then we can identify it and suitably wait for the block device that we will
then *know* will appear. If this is NoCloud, then I think ryan gave you some
options, and we can further improve nocloud too.

@Ryan,
I don't think that "cloud-init as a daemon" actually solves the problem at all. cloud-init aims to provide structured points at boot when a user (or cloud-init) can operate. If running later later (after such a device shows up) then cloud-init is not providing that point in boot and thus failing in a different way.