Meeting started at 2025-03-11 15:00:24 UTC

The Meeting name is 'fedora_bootc_meeting'

!hi

None (rsturla)

!hi

Hristo Marinov (hricky) - he / him / his

!hi

Colin Walters (walters)

!hi

John Eckersberg (jeckersb)

!hi

Miguel Martin (mmartinv)

!hi

Sean Thrailkill (snthrailkill)

!hi

Micah Abbott (miabbott)

!hi

Paul Whalen (pwhalen)

!hi

None (jlebon)

How's everyone doing today?

The agenda is https://etherpad.opensuse.org/p/bootc-initiative-meetings and it looks like we have something from mmartinv ?

!hi

Timothée Ravier (siosm) - he / him / his

For topics today, should we continue talking about the local layering issue? Or are there other topics on our minds?

cc gursewak re ⬆️

I have updated the https://gitlab.com/fedora/bootc/base-images/-/merge_requests/70 with the latest proposal

Waiting on https://github.com/konflux-ci/build-definitions/pull/1998 so we can refer the upstream pipeline instead of the patched one

Not sure if it will get accepted though, maybe we need to add the pipeline to the repo

Thanks so much for doing this! A lot to build on top of this, including especially things like keeping this pipeline in sync with what we have for centos stream, etc.

Can we get in sync on the subthread from https://gitlab.com/fedora/bootc/base-images/-/merge_requests/70#note_2385156856 ?

This whole effort started before I did work on the customizable base images; I think my preference here would be to start with the konflux build of what is now `standard` and also `minimal`

This also relates t ohttps://github.com/coreos/fedora-coreos-tracker/issues/1861

*relates to

It would be good if we could figure out a way to make the build pipeline logs public (I don't have access as far as I can see). But that can happen later.

This also relates to https://github.com/coreos/fedora-coreos-tracker/issues/1861

Colin Walters: do you perceive a high cost from building three instead of two?

at least for the time being until we have a clearer story around CI

Yeah, the FCOS Jenkins has the same issue still right?; but by "public" you mean "unauthenticated" specifically right? They're available to anyone with a FAS account AFAIK

I logged in with my FAS and could not access the logs

No, I wouldn't call it a high cost. But it's more a question of priorities and ordering I think

If I go to koji right now in the Fedora Infra, everything is public

it's also not just about packages I would emphasize. any glue code/workarounds/etc... related to the packages in that list can be more easily shared if it's a separate target and not intermingled with e.g. `standard`

FAS gated would be OK for me, but ideally we should not re-create the Jenkins situation that we have in FCOS, which is mainly because we don't want to expose Jenkins which has a terrible security track record

But I guess to ask directly, since it's not explained in the commit message but I can infer it: was the idea here that Fedora IoT would be `FROM quay.io/fedora/fedora-bootc:tierx` or so? Is there a tracker for that?

so it's about maintenance of that package set

travier: you need to create an MR to get permissions granted, see https://gitlab.com/fedora/infrastructure/konflux/tenants-config/-/merge_requests/9/diffs for reference

Colin Walters: that was what i expected (and similar for FCOS and Atomic Workstations eventually)

But it is the case currently AFAIK that there are no workarounds for anything not in minimal, right?

mmartinv: Yes, the idea is that I shouldn't have to do that

Colin Walters: currently, yes. but tier-x/minimal-plus ships openssh, NM, rpm-ostree, polkit, and a few other biggies

Unless you can use a wildcard the user field to provide all Konflux users access?

one can easily imagine things needed for those

travier: i think we'd have to ask the Konflux folks if that restriction could be relaxed

Unless you can use a wildcard the user field to provide all Konflux users access to a particular ro role?

maybe an issue on https://gitlab.com/fedora/infrastructure/konflux

there's https://matrix.to/#/#konflux:fedora.im as well

Unless you can use a wildcard the user field to provide all Konflux users access to a particular ro role?

Oh, it's Kubernetes native permissions, not something Konflux specific

Colin Walters: anyway, not strongly against not having it to be clear, but it just seems a much cleaner story to me to have an actual image variants build on top

https://gitlab.com/fedora/infrastructure/konflux/tenants-config/-/issues/3

I put this somewhere but one possible middle ground here is to ship `quay.io/fedora-ci/fedora-bootc-minimal-plus:rawhide` e.g. (note `fedora-ci` i.e. it's "fedora internal")

Yeah, that was the idea, not sure if we have a tracker though, Micah Abbott ?

that WFM

it seems fine to me if this is only for variants use

I still lean towards trimming down `standard` in the medium term

(Although it's quite complex because some things may need to be added there eventually...like `firewalld`)

It probably needs to be updated to reflect reality

I think the closest we have is https://github.com/fedora-iot/iot-distro/issues/53

@micah I'll try to update that this week.

Let's log some action items on these

?

For actions, i see something like "building quay.io/fedora-ci/fedora-bootc-minimal-plus:rawhide" and "updating https://github.com/fedora-iot/iot-distro/issues/53 with reality"

For actions, i see something like "building quay.io/fedora-ci/fedora-bootc-minimal-plus:rawhide" and "updating https://github.com/fedora-iot/iot-distro/issues/53 with reality"

anything else?

quay.io/fedora-ci is not a thing currently. i guess it could be under quay.io/fedora but just not in the main fedora-bootc repo

I edited the description of https://gitlab.com/fedora/bootc/base-images/-/issues/25

Ah sorry I meant https://quay.io/organization/fedoraci which is where ELN is

https://quay.io/repository/fedoraci/fedora?tab=tags

gotcha

Oh or at least it *was*...looks like it moved https://docs.fedoraproject.org/en-US/eln/deliverables/#_container_image

OK so we're hopefully closing in on different projects deriving from bootc base images finally

OK, is there more on this topic?

Do we have other items to discuss today?

not sure if i surfaced this in this meeting yet, but i did have a rough PR in https://github.com/coreos/fedora-coreos-config/pull/3348 of rebasing FCOS on top of minimal-plus

there's some work needed on the tooling side to enable this

Is minimal plus the same as tier-x?

what you'll notice in that PR that's neat is that there's not much actually going on in the `Containerfile`. we're reusing all the manifests we already have, just applied at container build time

Jason Brooks: yeah, that's the proposed new name

That's cool w/ the reused manifests

All right, anything else? Should we draw this episode to a close?

OK, we'll follow up w/ anything else in the bootc room