Unlike CentOS, our image creation process is a bit more ossified. But we are working on retooling things. We can try to accommodate this as part of that.

In my opinion, we should continue to maintain the major release, but then I don't have a problem with having the "modified date" or "creation_date" in there.

A "fedora latest" designation doesn't seem consistent with our release process
it seems like that would be like saying CentOS/Latest and getting 9 the next time you want to deploy when you are using 8.
Also, are we making enough images to have a "latest"?
right now, I don't think so.

Is this something we can maintain through the current methods that most public clouds provide? Similar to the naming conventions in GCP or AMI Public Parameters for AWS?

In my opinion, we should continue to maintain the major release, but then I don't have a problem with having the "modified date" or "creation_date" in there.

A "fedora latest" designation doesn't seem consistent with our release process
it seems like that would be like saying CentOS/Latest and getting 9 the next time you want to deploy when you are using 8.

This is an incorrect assumption. Why would you consider "latest" pointing to CentOS Stream 9 only? Both images have their respective URI path. Same goes for Fedora, this request is not about getting "fedora-latest", but getting a "latest" symlink for images of all supported Fedoras, IOW versions not EOL'ed, so you'd have fedora-36-latest, fedora-37-latest, etc.

Also, are we making enough images to have a "latest"?
right now, I don't think so.

The point isn't whether you're making enough images or not, but whether getting the latest image build of a given fedora version can be automated, because right now, it can't be without web scraping and comparing numbers or release dates - having a plain symlink named "fedora-<N>-latest while keeping your existing naming scheme will immediately alleviate this problem.

An easy way to fix that would be to have some kind of text or json file that gives you that information for a tool to parse as an API. That would also avoid the problems related to having symlinks on a server that needs to be mirrored.

An easy way to fix that would be to have some kind of text or json file that gives you that information for a tool to parse as an API. That would also avoid the problems related to having symlinks on a server that needs to be mirrored.

Well, technically yes, this would unarguably be a solution to the problem I described. Unfortunately for us, it wouldn't help as in our case we're relying on this information to come from libosinfo's osinfo database where this vendor OS information is stored statically in XML files (https://gitlab.com/libosinfo/osinfo-db/-/tree/main/data/os), so again, while I agree an API would likely help most, ours would not be the case.

whether getting the latest image build of a given fedora version can be automated, because right now, it can't be without web scraping and comparing numbers or release dates - having a plain symlink named "fedora-<N>-latest while keeping your existing naming scheme will immediately alleviate this problem.

Following changes on open source testing project I use, I recently stumbled again over the difficulty of grabbing the latest fedora box of a given version from a script -- especially the latest rawhide box. With the imagebuilder improvements over the past few years, is it perhaps easier to extend the infrastructure to have a symlink to the latest image per-version these days?

Thanks!!

discussed in the meeting with Davide Cavalca, @ngompa @jcline. Neal said that we would need to update pungi to make it work.

example naming: "Fedora-Cloud-Base-AmazonEC2-Latest.aarch64.raw.xz"

Per @ngompa

this is something that would be under pungi's remit
it collects the images and sets up the structure for publishing to mirrors, so this is just part of the publishing stuff but also, I don't think we actually push the daily update images to the mirror network?

Some random comments:

An easy way to fix that would be to have some kind of text or json file that gives you that information for a tool to parse as an API. That would also avoid the problems related to having symlinks on a server that needs to be mirrored.

Like fedfind? https://pagure.io/fedora-qa/fedfind

Naming images 'latest' for everyone would be pretty confusing. "I tested the latest image" "which latest?"

We do upload images daily.

Right, but we don't publish them to the mirror network, which means the generic cloud image isn't available.

We do? https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Cloud/x86_64/images/Fedora-Cloud-Base-Generic-Rawhide-20250317.n.0.x86_64.qcow2

For stable releases? I don't think we do. Same for Vagrant images.

ok, perhaps I misunderstood the scope here then, I thought it was talking about rawhide.

yes, for stable releases we don't mirror those images, although I think we do upload them to clouds.