ping @adamwill

Haven't had time to get to this yet. It's behind a bunch of other things on my todo list.

We now have COSMIC Live images as well, as a precursor to its expected addition to EPEL 10.

Post-recharge ping @adamwill

OK, so now I had a minute to look at this: why did you give them weird subvariants? eln-cosmic-live, eln-gnome-live, eln-kde-live...

"eln" and "live" aren't really necessary in the subvariant. "eln" is a property of the compose as a whole, not of the individual images. It's already in the compose metadata. "live" is already the image type, so putting it in the subvariant is unnecessary duplication.

We don't do this for any other images. The subvariant for the network install image is "BaseOS", not "eln-BaseOS-boot".

So the subvariants could just be "cosmic", "gnome" and "kde". In fact, if you'd used kde, openQA would probably have started running tests on the KDE live with no changes needed at all.

I'd still have to change something for GNOME because the Fedora images have the subvariant as "workstation", not "gnome", and you probably don't want to use "workstation" in ELN. But it'd be more in line at least.

oh, I see https://forge.fedoraproject.org/releng/pungi-fedora/pulls/1568#issuecomment-245767 , but that sounds like your tooling is wrong. You should not be relying on ELN's subvariants being "unique", that's absolutely not the point of the subvariant field (or the variant field, for that matter). Your tooling needs to check that it's working on an ELN compose. Can you point out the tooling in question?

oh, I see https://forge.fedoraproject.org/releng/pungi-fedora/pulls/1568#issuecomment-245767 , but that sounds like your tooling is wrong. You should not be relying on ELN's subvariants being "unique", that's absolutely not the point of the subvariant field (or the variant field, for that matter). Your tooling needs to check that it's working on an ELN compose. Can you point out the tooling in question?

By "ours", I meant Fedora's as a whole, not ELN's, e.g. https://pagure.io/cloud-image-uploader/issue/62 where you said yourself, "I tend to ignore variant entirely and only go on subvariant, I've never yet found a case where it was necessary or useful to take the variant into account". This is common from what we found, and therefore it was too risky to use subvariants that matched Fedora composes lest the ELN images be mistaken for Fedora ones and e.g. be uploaded to the wrong location.

Granted, the live images aren't uploaded to quay like the base and toolbox container images, but QA seems to rely (only) on subvariant as well. I don't think it would be too disruptive to rename the subvariants of the live images right now, but it doesn't seem safe to use subvariants which match those of Fedora composes either.

If we stick with the lower-case convention for ELN and use "cosmic", "gnome", and "kde", do you think that would be safe, and would that make this easier? (Theoretically "i3" would be a potential conflict, but being X11-only I doubt we would ever have that package in EPEL 10+ much less have a live image for it.)

/cc @tdawson

Well, when I said "only go on subvariant" there, I just meant "for the task of identifying the payload of the image, subvariant is sufficient, there's no need to also consider variant". For identifying the distribution the compose is for, or the type of the image, there are other properties.

Canonically, with productmd, to uniquely identify an image within a compose, you use subvariant, type, format, arch, disc_number, unified and additional_variants - see https://github.com/release-engineering/productmd/blob/master/productmd/images.py#L123 . Two images in a compose can never have all of those properties in common. For Fedora purposes I tend to shorten this to subvariant, type, format, arch, the others are all EL-specific I believe.

Anything I wrote will usually consider the shortname of the distribution the compose is for, and its release number, then the image subvariant, type, format and arch (this is how the openQA scheduler works for e.g.).

Having had a quick look through, fedora-image-uploader does in fact seem to be a bit sloppy in not considering that images might not be from the compose it's expecting them to be from... the container code notices ELN composes by them having the version 'eln' and handles them specially, but the cloud handlers don't seem to do this, so if you were to add cloud images to ELN with the same properties as Fedora's cloud images, it might do something unintended (though since the ELN release number is 'eln' it wouldn't overwrite Fedora images, probably). But the correct fix for that is to improve f-i-u's handling, not start encoding other properties into the subvariant property. All the scaffolding for that is in place - f-i-u passes a fedfind release object around from the top-level consumer to the various handlers, and that object has all the necessary information about the compose. The handlers can use it, just so far some of them aren't.

I would say in general I'd actually want equivalent images from the different composes to have the same image identification metadata precisely so that tools can treat them similarly. For e.g. the openQA scheduler case - I would want the openQA scheduler to trigger the KDE live image tests on ELN's KDE live image exactly the way it does on the KDE live image from any other given Fedora compose,, why not? If we need to do any special handling we can do it when we notice the compose is an ELN compose.

Hum, actually, I may be doing the cloud handlers in c-i-u a bit of a disservice. The AWS one at least seems to be explicitly handling ELN, there's an ELN conditional in there, and there are ELN-versioned images in the AWS marketplace. So it's all working as intended, by the looks of it. I don't know how to check the GCP and Azure catalogs quickly, but they're probably fine too.

c-i-u is indeed working, but in the process of getting there we learned about the hazards of subvariant naming. This is why I hesitate to use the same subvariants as Fedora.

In any case, I wouldn't want to use "Workstation" either way. If we go with gnome, kde, and cosmic (lower case, where Fedora uses capitalized or upper case), would that work for you?

Sure.

https://forge.fedoraproject.org/releng/pungi-fedora/pulls/1597

This landed for 20260116.n.0, per the compose changelog:

===== ADDED IMAGES =====
kde live aarch64
gnome live aarch64
cosmic live x86_64
kde live x86_64
gnome live x86_64
cosmic live aarch64

But nothing new was triggered in OpenQA:

https://openqa.fedoraproject.org/tests/overview?distri=fedora&version=eln&build=Fedora-eln-20260116.n.0&groupid=1

hmm, OK, I'll look at it tomorrow. I would've expected kde live x86_64 to fire.

oh, hey, it looks like we don't actually nerf case in the openQA scheduler, so it specifically wants 'KDE', not 'kde'. OK, well, I'll just change that then. But not right now as I may as well roll it in with a bigger change to deal with the 'gnome' vs 'Workstation' thing somehow.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/quality/os-autoinst-distri-fedora/issues/452

Please continue any further discussion there.