@kevin Do you know who has permissions for fedora namespace on quay.io? I don't think this was set up by Fedora Infrastructure.

All the folks there in the fedora admin team:

    dustymabe   Team member 
    cverna  Team member 
    mohanboddu  Team member 
    siddharthvipul  Team member 
    dkirwan Team member 
    kfenzi  Team member 
    samyakjain Team member

as to this request... 'fedora-netboot' is kind of generic... we have several deliverables called 'netboot' or the like.

Would it be possible to use something like 'fedora-bootc-net' or 'fedora-bootc-netboot' or something?
Or can you explain more about what this deliverable is?

@kevin The primary goal is to enable bare-metal cluster installations to provision from a bootable container, so in that sense it is related to bootc, however the secondary goal is to improve secureboot provisioning in general and this has no relation to bootc, hence we picked a more generic name for the repo that would encapsulate storage or network bootfiles as artifacts in the registry.
If the suggestion to be more specific to represent our primary goal then we can, I guess, go with the fedora-bootc-netboot.
@lzap can you chime in please on the naming preferences?

We are struggling to find the best name. It is gonna be a repository for boot-related files: shim, grub, kernel and initramdisk with anaconda image. We want to use this for network booting via Foreman / Satellite - instead of quite complicated downloading key files from RPMs (shim, grub) these can be easily just "grabbed" from the registry. So we landed on "netboot", could be alternatively something like "fedora-boot-files" or "fedora-anaconda-boot" that is getting maybe too long. I would suggest not to put "bootc" into the name as these files are usable also outside of the bootc context.

The netboot name came from the fact that inside of the repository we plan to ship the following files:

• shim.efi
• grubXXX.efi
• pxelinux.0 (if present)
• vmlinuz
• initrd.img
• install.img
• boot.iso (also known as Fedora-netboot.iso)

Ideas:

fedora-boot
fedora-installer
fedora-boot-installer
fedora-bootable-installer
fedora-instboot
fedora-bootinst
fedora-network-boot
fedora-netboot
fedora-netboot-iso

This is really hard :-)

@kevin given the provided background, could we go with fedora-netboot unless you fancy more some other option?

ok.

So, thinking about this more, it's making me a little uneasy, because it seems like we are advertising fedora images that are produced seperately from fedora without passing through any fedora community process. I know the images are produced from fedora packages and I know you all are doing things transparently, just worried people will start depending on/advertising these as 'official fedora images'.

Would it be at all possible for us to put them under a fedora-testing or something namespace? Or would that be too disruptive?

or are you setting user expectations such that it's ok to have them in the main namespace?

I share @kevin 's concern that there needs to be some more proposal/planning/discussion of this for it to live under the 'fedora' top-level namespace. A Fedora Change would be a good place to start.

For an experimental/PoC/testing implementation that is not necessary, but as Kevin says, I don't think that should go in the 'fedora' namespace.

edit: tag @walters since he's on https://gitlab.com/fedora/bootc/tracker/-/issues/21 .

for @kevin and other CPE folks, there seems to be more background on the goal here at https://github.com/pulp/netboot-oci-specs and https://github.com/pulp/netboot-oci-specs/issues/6 .

Fair enough, this is my first time contributing an official Fedora feature. I will start drafting a Change Proposal right away. Any other tips or instructions for us for this particular feature? I mean, is there anything special that might not be covered by Fedora documentation or guidelines?

I understand that for the proposal, we can keep the testing repository in our own namespace (username or pulp/foreman quay.io orgs) until it gets approved and only then we can resurrect this ticket and ask for fedora-testing namespace. Does that sound right?

Ina, I propose to do the following:

1) Figure out a good name for this, I think "netboot" is a bit misleading and "bootc" narrows the scope too much as this is usable outside of bootable containers context.

2) Add artifact signing to our prototype CI/CD pipeline so everything is ready by the time we are announcing the proposal.

3) Draft, review and propose the Change Proposal document and continue from there.

I do think we want these artifacts to live under fedora namespace. If submitting a Fedora change is a prerequisite to make folks feel more comfortable and confident, let's go for it.

We brainstormed some more naming ideas with @lzap and landed on fedora/kickstart-artifacts. We'll roll with the fedora change and see if the name will stick.

I understand that for the proposal, we can keep the testing repository in our own namespace (username or pulp/foreman quay.io orgs) until it gets approved and only then we can resurrect this ticket and ask for fedora-testing namespace. Does that sound right?

I think we were saying that we'd be fine with setting up something like fedora-testing as @kevin suggested, without the need to go through the full Change process. It's just we don't want it under fedora with all the official deliverables that are produced through known processes.

I will start drafting a Change Proposal right away. Any other tips or instructions for us for this particular feature? I mean, is there anything special that might not be covered by Fedora documentation or guidelines?

I think the main topic that needs to be addressed is what makes this a "Fedora deliverable"? We currently kinda have two broad categories of these: Fedora CoreOS, and everything else. FCOS has an entirely separate build/release pipeline for historic reasons (tl;dr: Red Hat bought it). At the time it became a Fedora Edition, AIUI, releng kinda gave it a once-over and said it was OK. @kevin would know more about the details of that, I guess. I thought we required that the process be documented somewhere; I can't find a single document right now, but it is fairly well explained in various repos, e.g. https://github.com/coreos/fedora-coreos-pipeline , https://github.com/coreos/coreos-assembler and https://github.com/coreos/fedora-coreos-config .

Everything else is built by some kinda process releng ultimately runs, and they all (I think) ultimately come out of 'composes' run through pungi. We do a bunch of different composes on different schedules. The easiest round-peg, round-hole way to add something on from releng's perspective is probably to make it a thing pungi can do and add it to some of the existing composes (rawhide/branched nightlies and stable container nightlies, in this case, probably). We don't have to do it that way, but that way would probably run into the fewest questions and roadblocks. We currently build container images using Kiwi, so if it was possible to build this thing via Kiwi, it should be relatively simple to add it to the existing compose process.

There's a possible expiry date built into the pungi-based approach - it's called Konflux. If the idea was to build this thing through Konflux, that might actually be great as it'd give releng a test project for building something useful with Konflux (just MHO, @kevin may not agree). But if the idea is to have a different pipeline, it might take a bit more convincing people, because then we're just adding to the list of different release pipelines we have to keep track of: the pungi-based ones, FCOS one, the approaching Konflux, and now another new one too.

If you do choose to propose adding a new pipeline, the kinda things that would need addressing I would guess are...

• Open source - AFAIK, both the existing pipelines are entirely open source. I'm not sure this is an absolute hard requirement written down formally somewhere, but it's always been the case and I imagine there might be substantial resistance to a non-open source pipeline for Fedora deliverables.
• Documentation - it would help for the way the pipeline works, all its inputs etc. to be clearly documented.
• Observability - Fedora is generally an open project, people should be able to 'see' everything happen (like you can go to koji.fedoraproject.org to look at builds, https://kojipkgs.fedoraproject.org/compose/ to see the pungi composes, and so on). It would probably be difficult if regular Fedora users could not observe the compose process, with access to logs and so on.
• Consistency/contents - this is kinda the "are we sure it's Fedora?" bit. It's good if people can be confident about what goes in it, and that this will be consistent with what's in all the other things we call "Fedora". The more clear and reliable it is that the stuff in the container comes only from the appropriately-tagged Fedora packages, or out of the pungi composes, or whatever, the better.

That's all just my opinion, but based on past experience it's what I expect to come up in evaluation of any new pipeline for a Fedora-branded deliverable, and if the Change proposal addresses it upfront I imagine it'd help. Kevin may well have more/better thoughts.

I see the idea behind a Change, I think it makes sense. However can we meet in the middle and make the change retroactive? To the best of my knowledge what "netboot" means has not really changed in many years in Fedora versions so I see no reason not to ship a :40 version immediately as well.

(One overall challenge we have is keeping things in sync with rhel-targeted changes, and the Fedora 6 month cycle can sometimes be quite slow and result in times where we end up shipping something in c9s first just because of that. For things like this that have basically zero impact outside of their own "domain" I don't see any issue with at least ensuring it's "shipped" in fedora:$stable at the same time as c9s/c10s etc.)

I don't see why that'd be a problem, personally, no. We already do nightly container composes for stable releases.

We started building a prototype at

https://gitlab.com/fedora/bootc/netboot/netboot

with plans to move it to Konflux once ready.

Btw initial draft of the Change is at https://fedoraproject.org/wiki/Changes/KickstartOciArtifacts we are currently reviewing it. Comments welcome.

yeah, if you mean that when the change is approved you would ship not only rawhide/whatever but the stable releases too? I think thats not a problem at all.

Thanks for working on the change! Sorry for tossing process in the way, but I think it will be a advatage in the longer term (increasing visiblity, coordination, etc).

I guess I'd say lets close this for now and you can re-open or file a new ticket when ready.

Thanks!

I do feel like if this is intended to "move to Konflux once ready" it might be nice to use it to help us get Konflux ready. We already have a test Konflux deployment that @ralph set up for us; maybe we could try building this on that?

Yeah, I think that would be a excellent plan.

There is already a tracker to transition builds to konflux. It will take some time until everything under that namespace will move to konflux. Some work has already been started, eventually, also pipeline for kickstart-artifacts will be moved there, just probably it won't be there among 'first' ones https://gitlab.com/fedora/bootc/tracker/-/issues/33

ty for confirming that applying the change retroactively won't be an issue!