Comment 9 for bug 1855458

> > Looking at the output provided, all we can tell is that we're on
> > VMWare, but no indication that it's OpenStack, so cloud-init can't
> > reasonable expect to know that it should enable the OpenStack
> > datasource.
>
> Let me mention again that this bug was introduced in Ubuntu 18.04; previous versions do not suffer from the same problem.

It's not a bug, but I understand from your perspective that it appears to be one.
We introduced ds-identify to prevent cloud-images from attempting to connect
out to URLs when none are available. Cloud-init was slower since it needed
to attempt to see if any network-based datasources were present and this
also prevents cloud-init from responding to network sources when it should not.
Cloud-init would also run even if no datasources or user-config were provided
at all which meant running a cloud-image outside of a cloud would hang for
a very long time waiting for cloud-init to timeout.

>
> Also, if I modify the official cloud image and disable any datasource
> *except* Ec2 (i.e., write `datasource_list: [ Ec2 ]` into
> `/etc/cloud/cloud.cfg.d/90_dpkg.cfg`), then everything works fine.
>
> So the issue is really `ds-identify` being too picky about when the
> `Ec2` datasource is valid; from a cursory look, I can see that it just
> checks if `/sys/hypervisor` contains some well-known AWS tag -- but
> there are many cloud services which provide EC2-compatible metadata
> (OpenNebula being another example), which would be skipped by this
> logic!

The ds-identify checks use local information on the instance to check
if it is running on a cloud platform. For OpenStack, the method used
is to set DMI values to indicate the VM is running on OpenStack.