#8 Cloud images incorrectly named (PRODUCT and SUBPRODUCT separated with - not _, no image type in some cases, arch in wrong place, wrong version)
Opened 8 years ago by adamwill. Modified 8 years ago

The file names for Cloud images coming out of Pungi 4 seem pretty thoroughly wrong at present. Here's a couple of examples:

  • Fedora-Cloud-Base-Rawhide-5.i386.qcow2
  • Fedora-Cloud-Base-Vagrant-Rawhide-4.i386.vagrant-libvirt.box

there are several problems:

'Base' here is what the naming policy refers to as SUBPRODUCT. It should not be separated with dashes, because that makes the number of fields in the name inconsistent with images that have no subproduct and consequently makes parsing the name harder. As per the policy it should be separated with an underscore: Cloud_Base, not Cloud-Base. (possibly we don't need this at all any more, since the only two 'subproduct' types we have are 'Base' and 'Atomic' for Cloud, and it seems we're going to make Atomic a separate variant, thus there's nothing left for 'Base' to indicate, really).

The plain disk images have no 'image type' indicator, which is required by the naming policy.

The vagrant images seem to indicate the image type twice, once in the right place but also at the end of the filename, which seems egregious and unnecessary.

The arch appears in the wrong place in the image name (and is separated with dots rather than dashes). The naming policy requires it to appear between the imagetype and the version, separated with dashes.

Finally the 'version' appears incorrect. For all other images, the 'version' is pungi's (date).(respin) format, but for cloud images it appears to be some sort of incremented integer.

Put it all together, and the names should rather look like this:

  • Fedora-Cloud_Base-appliance-i386-Rawhide-20160224.0.qcow2
  • Fedora-Cloud_Base-vagrant-libvirt-i386-Rawhide-20160224.0.box

again using the sensible 'appliance' type Pungi has, rather than the useless 'raw-xz' type productmd has.

it's particularly unfortunate that there are dashes in the vagrant 'image type' names, as it makes parsing the file names unnecessarily difficult, and violates the naming policy, but that's a separate issue.


Login to comment on this ticket.

Metadata