This is to work around this kind of failure. Updating the db schema seems like a drag.

This seems like it should be easier, but I don't know if there are hidden landmines with doing this kind of "upload the file under a different name" thing. It seems like it is also used in the createLiveMedia task, at least, and I don't see anything scary there on a quick look, but maybe I'm overlooking something.

@adamwill New file type can be added by "koji call addArchiveType". See "koji list-api addArchiveType". Maybe it makes sense to pull it to CLI command to be more easily discoverable?

yeah, I think we wound up just adding this archive type, right @kevin ? In any case, we certainly wound up with a successful Beta-1.7 compose in which the image is vhdfixed.xz - https://kojipkgs.fedoraproject.org/compose/40/Fedora-40-20240317.1/compose/Cloud/x86_64/images/

Yeah, I just added that to the existing type. I think it might be good to land this upstream though so it's set that way by default for new installs.

well, this isn't the same thing, this made koji rename the image. maybe we should just land an addition of it to the default list of image types upstream...

If we want to add it to default extensions it probably makes more sense to update extensions list for 'vhd' instead of adding new 'vhdfixed' type?

UPDATE archivetypes (name, description, extensions) VALUES ('vhd', 'Hyper-V image', 'vhd vhdfixed') WHERE name = 'vhd';

yes, I believe that's what we did in Fedora koji.

oh, well, actually, the image comes out as vhdfixed.xz , so we added it to vhd-compressed . So something like:

UPDATE archivetypes (name, description, extensions) VALUES ('vhd-compressed', 'Compressed VHD image', 'vhd.gz vhd.xz vhdfixed.gz vhdfixed.xz') WHERE name = 'vhd-compressed';

i guess? But maybe do both, as it doesn't hurt to support both uncompressed and compressed images with vhdfixed extension...