Consider more efficient ways of supporting additional cloud platforms

[jlebon]

Describe the enhancement

Right now, we're shipping a separate image for each cloud platform we support. Sometimes, that means actually shipping in the same disk format with just different platform IDs stamped in. For example:

• aliyun, ibmcloud, openstack, and exoscale all use the same QCOW2 format
• azure and azurestack use the same VHD format
• vultr and metal are in raw format

There is now a request to add another cloud platform which looks like it might require a VHD and an OVA.

More cloud images means more storage and longer pipelines. It seems highly inefficient to store multiple versions of e.g. a qcow2 with essentially just a few bits different.

Let's brainstorm whether there are ways to improve the situation here without sacrificing the UX too much.

[jlebon]

One random idea I had was to teach coreos-installer to restamp platform IDs in some artifacts. E.g. coreos-installer download -p cloudstack for example could just download the QEMU qcow2 and do some bit-level fiddling to change the platform ID to cloudstack. (Not sure yet how hard that would be on a technical level).

Obviously the downside there is that users can no longer just grab a URL to the cloud image they need, and it would elevate coreos-installer to a much more important tool, which for whatever reason might be cumbersome to run in some situations.

[jlebon]

One thing we could start doing is to not produce every artifact for every build of every stream. E.g. for testing-devel/next-devel/rawhide, it seems like overkill to produce images for clouds we don't actually run any tests on and which are "pure restamps" of some other image (e.g. aliyun, ibmcloud, and exoscale). (But we do still make sure that we test at least one restamp to exercise that path. In the case of qcow2s, we still create openstack images).

[dustymabe]

There's no real good answer here that helps the problem and doesn't degrade the user experience (i.e. by making them do some step or use some specific tool to reconstruct the image). The only thing I can think of that doesn't take away from the UX but does help with long term storage costs is if we initially produce all the images, but then later remove all non essential images (images that can be easily reconstructed) from the object storage.

The other side to that is that we never store non-essential images and we use a smart server to serve web requests for them and reconstruct them server side.

No option is without drawbacks :(