Meeting started at 2026-07-28 16:01:27 UTC

The Meeting name is 'ELN SIG 28 Jul '26'

The Meeting Name is now eln

!hi

!hi

!hi

bot seems to be sleeping, but hello all

big news!!

🥁 [jligon](https://matrix.to/#/@jligon:matrix.org) !

All merged and ready to make containers!

!hi

Awesome.

Thanks to everyone(lots of people) who helped!

I know that it has issues with cookies (sorry to intrude)

Is this zodbot?

it already *is* building containers

First ELN, tomorrow the world! Muahahahah

Tomorrow means the Surface.

(Niche reference no one will get)

!hi

https://quay.io/repository/bootc-devel/fedora-bootc-eln-standard?tab=tags

I have a small question about the `bootc` containers, Yaakov fixed the grub2 EFI vendor being 'wrong' (based on os-id instead of efi_vendor macro), that landed in ELN *before* the bootc container of today was built but the bootc container of today had the old version in it.

the grub2 fix landed in the 20260728.n.0 compose, so the next bootc image build should have it (the current latest was a bit early)

Was that expected (I don't know where it builds *from*).

MR in eln channel for shipping 20-RHEL.toml as well

Ah it was just timing?

yeah I think so

Ack.

[jligon](https://matrix.to/#/@jligon:matrix.org) do we have any control over the timing? because ELN composes are on a different schedule than rawhide's

Does it need to be on a timer or could we set something up to trigger it?

It builds with the rest of the bootc images. We have control over that in the form of asking them to change the cadence?

do you happen to know how that is defined?

In the bootc-dev influx tenant

And what is an “influx tenant”?

Konflux on a phone

lol

Geez, we can’t get it to work in a data center, but you have it running on your phone?! 😅

Containers all the way down bud

But what does “in the tenant” mean? It’s monkey-patched on the builder?

seriously though, that's one of the million repos you have to touch to get anything done with konflux?

The tenant is basically a namespace with its own settings, users, and permissions within which workloads run (probably wrong terminologoy).

And that differs from what I said in what practical way?

Sorry, that came out argumentative

I meant to indicate that I genuinely don't know

That's OK, I don't have a good answer either way.

afaik everything in konflux is defined in yaml, so probably not monkey-patched but "properly" configured, just that there's seemingly a *lot* of configuration needed for anything konflux

From what I've seen, it's just *barely* shy of implementing a turing-complete version of YAML

Anyway, I don't mean to rain on this achievement. Great work jligon and those that helped along the way!

so as mentioned above, we do have builds flowing now, and Simon found a few issues in early testing, for which fixes are incoming

jligon do you know how to go about getting these images published as quay.io/fedora/eln-bootc?

Sorry, had to sell a piano. Reading back

lol

Would this be in cloud-image-uploader?

jligon: Not going to lie; I read that and the first thing I did was step to the side and look up.

lol

https://docs.fedoraproject.org/en-US/infra/sysadmin_sops/cloud-image-uploader/#_containers suggests so

We should probably reach out to Jeremy Cline

Are they pushing there already?

I think cloud-image-uploader doesn't handle things produced with Konflux?

From my understanding of konflux, which is very little, it can push to registries so none of that goes through the uploader

Presumably it will need credentials to do so

it's already pushing to quay.io/fedora/fedora-bootc, this would just be a different image to the same org

Ah

right?

```

The goal is to move to Konflux and deprecate the Pungi-IoT mechanism.

```

Konflux → quay.io/bootc-devel/fedora-bootc-* (Development)

Pungi-IoT + cloud-image-uploader → quay.io/fedora/fedora-bootc (Production)

The fedora-base-bootc image is published via two parallel mechanisms:

Oh we might've done that back in the day, but I don't know if that's still true at the moment.

If it says so I guess it still holds true.

In that case the bootc container should actually be built ... in Koji?

doesn't look like there have been any such builds in koji for a while

Yeah, I assume the docs just got left behind

but quay.io/fedora/fedora-bootc is current

(as usual for software development)

so yeah old docs

Yea, I'd have assumed so; though I still see an `ostree_container` section in IoT's pungi config.

I don't recall if `ostree_container` actually is a Koji task or if it runs locally on the compose host.

Let's just assume it's old docs.

I concur

(seems to be that `ostree_container` spawns a `runroot` task in Koji).

so something is uploading the konflux bootc-devel builds over to fedora, but we have no idea what?

I think it's a good summary that we have no idea what is producing and uploading the containers that are published under the `quay.io/fedora` namespace.

I think that's an accurate summary. A good one...

But we *do* know that the containers under the `quay.io/bootc-devel` namespace are produced and uploaded through Tekton tasks on Konflux.

there is a mention of fedora-bootc in https://forge.fedoraproject.org/infra/ansible/src/commit/d34b8df20477ccb5de503d5e7eabeb6484992577/roles/openshift-apps/cloud-image-uploader/templates/config.toml#L120

Anyhow, maybe !action to figure it out :)

anyone volunteering?

Yes, I need to learn Konflux.

Even though I don't like it, feel free to give it to me.

anything else on this?

should probably update the tracker, that should be me

already done

sweet!

I'll open a new ticket for the quay.io/fedora publishing

Yep and please assign that one to me so it shows up in my overview :)

ack

Yep, and I've validated the ec2 images by spinning them up on AWS.

Let me do the other updates as well, I don't have much time before I have to run to the FESco meeting.

go ahead

There's a PR open for Azure + GCE; we noticed that there were no RHEL definitions for GCE/aarch64. I've created and merged a PR upstream to enable GCE/aarch64 in `image-builder` for ELN.

This is in 77.0 which is currently going through rawhide.

I'll update the PR to also enable aarch64 builds tomorrow (or as soon as 77.0 is in ELN) and then it should be ready to merge?

yeah, do you have a way of testing any of those?

I do.

We have cloud accounts everywhere in our team, so I should be able to spin them up everywhere.

wonderful

I've used AWS before but not the others

As for Azure and EC2 we already test these images by booting them in the respective clouds in `image-builder` CI but it's good to verify that it works end-to-end as well.

GCE support for our CI isn't there yet, so that one I'll have to do manually.

Other than that; after those the hyperscalers are done and we can take a look at container/wsl I think.

sounds good!

I've also spoken to cloud-virt about ELN and they don't have capacity /right now/ but want to start thinking and looking at things soon.

for what?

What they want for RHEL 11 in regards to the cloud images.

For example, dropping all that firmware.

imo we should just drop it in ELN, and then they can decide what to do for rhel 11

it will give them something to help evaluate the decision

Yea the question here is how close should ELN adhere to be RHEL.

But that's above my idea, if you want me to drop it; I'll drop it.

And then if it needs to go back, that's a separate discussion.

we should be targeting where RHEL is heading, or where we think it's heading with whatever information we have

(apparently we support passthrough even on hyperscalers, thus the firmware)

ah

linux-firmware, right?

So it's not as cut and dry as 'it never gets used'.

let's discuss this separately then

Yep.

interested in that discussion myself

we're just about out of time

Thank you; that's all from me and I really have to run so I can grab a drink before the next meeting.

If you file an issue about it we can chat about it there.

thank *you* for all your work on this

my pipe dream is have it like in suse where we can load firmware on demand, but out of caution we're still installing a lot of firmware at work too, we just contributed to making it a bit more modular

sorry but need to wrap up so that some of you can get over to fesco

any conflicts next week?

I'm running FESCo so I also need to run :P

I think I'll be here

2 minutes left

let's wrap it up?

Simon's already gone anyway

thank you all for coming, see you in channel or back here next week