I see where are you coming from but these are just speculations at this point. Whether it’s a CDN, mirror or registry, storage is expensive in the same way.
We are not taking away the ‘legacy’ way from which users can just retrieve needed kickstart assets from RPM mirror, we are adding yet another, cloud native way. Let’s not decide for people how they want to use or manage registry workflows. There is a clear tendency to use registry as a storage and people who have usecase for this are happy with that.
Quay.io specifically has some rules around registry’s repo pruning, and tbh kickstart updates are not that frequent.
Oh I did not mean removing the ISO after this effort is approved, implemented and files actually being published. What I mean is that if you do not like the idea of shipping the extra ISO via OCI registry then we will simply not do it. That file is a “bonus” content just like it is present in kickstart repo where it has no specific purpose I am aware of. At least Anaconda itself does not download it.
I acknoledge your concern about publishing the ISO and I am ready to remove it from the proposal and only go with all the other files. In fact, you can recreate the original ISO with all the other files and tools from Fedora (xorriso, mtools or mount, md5implant and few others) so it is really not necessary.
Can you be more specific? I checked with quay.io folks and they confirmed this amount of data is not an issue.
I do see the point that OCI/docker protocol is not a “dumb” protocol, meaning Fedora infrastructure team would need to deploy a new service in order to continue providing the content. If what you foresee happens then it also means that the whole Fedora Bootable Container is also dead as there is no longer a place where it can be published, thus this whole effort is also no longer relevant and it can be just dismissed.
You bring an interesting point here, while the plan is to remove unsupported Fedora versions from the repository and garbage collect old commits, there is no plan about what to do with old content. There is a format that most OCI tools understand called “OCI archive” and it is essentially contents of the repository as a TAR archive. Tools like skopeo or other tools based on the official OCI image library can work woth this format.
What is important is that such a TAR file can be easily hosted on any kind of HTTP(S) web server alongside other Fedora content (RPMs, dnf), a good place which pops in my mind is https://archives.fedoraproject.org. This is a good fallback mechanism we can incorporate in the tools we want to build for this giving a reasonable exist strategy for Fedora. In fact, we can make this part of the spec, what you think @ipanova ?
I do worry about this too. Aside from my concerns that I think the OCI format as it is now is not a good medium for operating system images (I really would like to see OCI use erofs instead of tarballs to increase fidelity to more closely match what we get with conventional disk images), I worry in general that storing whole conventional operating system images and layers and all this stuff in OCI registries is going to turn into a “this is why we can’t have nice things” moment when the screws get tightened on the public registries due to the surprise of hosting too much stuff.
This stuff is expensive and takes a lot of space (especially with the layers). And the elimination of local client-side operations (requiring everything to loop through server infrastructure and container registries) adds even more pressure for that.
Quay has some rules about content retention. As long as the manifest is tagged it will not get garbage collected. They also have some sort of ‘tag expiry’ rule that can be configure per repo as well. To be honest i would just follow same content retention rules as the ones set for fedora bootable container repo.
I think you’re misreading things a little here. What you’re calling a “kickstart repo” isn’t…really…that. It’s just a directory in the compose where we put stuff.
There’s been a os/images/boot.iso in every Fedora release ever, all the way back to Fedora Core 1. At that time there was no other place in the compose to get a “minimal boot” image; that was it. If you read https://dl.fedoraproject.org/pub/archive/fedora/linux/core/1/x86_64/os/README , it describes that directory (as transposed to the CDs) as the location of “boot disk ISO image”, nothing about kickstarts (though it did in fact also contain a pxeboot directory with a kernel and initrd). Back in those days, the overall “plan” was that the os directory contained all the actual bits of “Fedora”, and the iso directory contained ISO images with the contents of os on them.
In Fedora 7 things started to get a bit more complicated because the Everything, Fedora and Live directories showed up, but there still wasn’t anything but boot.iso. The first release with a netinst.iso was Fedora 9. From that point on, AFAICT, the boot.iso and corresponding netinst.iso files have been the same, they’re hardlinks to the same data. I actually can’t figure out which one gets built first and then linked as the other, the paths around this stuff in pungi are very twisty. I’m pretty sure we keep an os/images/boot.iso around just because there has always been one, and somebody or some script might still be looking for it.
Oh thanks for such a nice writeup, indeed, I was confused. Also some of this confusion stems from my work on Satellite where Pulp does not synchronize some files just these which are in .treeinfo so that is why I had an impression that some directories had no ISO files. Now it makes sense, it was always there, I was just looking at Pulp copies way too often.