Introduction of subplatform around 18.5 broke ConfigDrive

[NoRefill]

I create custom LXD images from Ubuntu minimal images for an OpenStack environment based on LXD containers and the images I created worked on Ubuntu 18.04 hosts until around the cloud-init v18.5 release where subplatform was introduced. My images produced this error:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 760, in find_source
    if s.update_metadata([EventType.BOOT_NEW_INSTANCE]):
  File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 649, in update_metadata
    result = self.get_data()
  File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 276, in get_data
    self.persist_instance_data()
  File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 306, in persist_instance_data
    self._get_standardized_metadata())
  File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 246, in _get_standardized_metadata
    'subplatform': self.subplatform}}
  File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 419, in subplatform
    self._subplatform = self._get_subplatform()
  File "/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceConfigDrive.py", line 170, in _get_subplatform
    return '%s (%s)' % (subplatform_type, self.source)

This code uses and if/elif which leaves subplatform_type undefined on my image. I don't have any idea what this is supposed to be, but looking at other DataSources, they use an if/else so that subplatform_type is alway defined. The diff that makes this work for me and works like other DataSources is attached.

[NoRefill (david-kindred)]

This is the patch diff that makes cloud-init 19.2 work for me.

[NoRefill (david-kindred)]

This is the result of running "cloud-init collect-logs" from the failed container.

[NoRefill (david-kindred)]

Just wondering if the priority on this can be bumped. This was released into an Ubuntu 18.04.3 LTS release and broke compatibility. There is a simple patch attached.
Thanks.

[Chad Smith (chad.smith)]

Hi David,

 Thanks for this patch suggestion and yes we'd like to prioritize this fix as soon as possible. Would you be able to sign the CLA and put a branch proposal up with your patch suggestion plus the following unit test I've added?

CLA signup page https://ubuntu.com/legal/contributors

I've reviewed your branch and added a unit test to cover this change here
https://paste.ubuntu.com/p/TQxBnQPrz4/

Once you confirm signing the CLA for this code contribution we can immediately include you changeset in cloud-init.

To submit a branch for inclusion in cloud-init https://cloudinit.readthedocs.io/en/latest/topics/hacking.html

Also, don't hesitate to join us in #cloud-init channel on FreeNode with any questions and we'll get you fast-tracked through your initial cloud-init contribution. Again, thanks for making cloud-init great!

If you don't have an IRC client, opening this link in a browser will let you easily join and chat in our developer channel https://webchat.freenode.net/?channel=#cloud-init

[Server Team CI bot (server-team-bot)]

This bug is fixed with commit 15fa1546 to cloud-init on branch master.
To view that commit see the following URL:
https://git.launchpad.net/cloud-init/commit/?id=15fa1546

[Chad Smith (chad.smith)]

This bug is believed to be fixed in cloud-init in version 19.2-79. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3483