Meeting started at 2025-03-18 15:00:46 UTC

The Meeting name is 'fedora_bootc_meeting'

!hi

Colin Walters (walters)

!hi

John Eckersberg (jeckersb)

!hi

Hristo Marinov (hricky) - he / him / his

!hi

None (jlebon)

How's it going, everyone?

!hi

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

!hi

Micah Abbott (miabbott)

!hi

Joseph Marrero (jmarrero)

I apologize, due to UTC vs non UTC, I have overlapping meetings atm 🙂

!hi

Miguel Martin (mmartinv)

What topic do we have today?

Clement asked that we talk about https://gitlab.com/fedora/bootc/base-images/-/issues/25#note_2402386978

It looks like conversation continued in there

Colin Walters: Do you have items to discuss today?

Really great to see the progress there!

I think the async discussion is going ok, overall my feeling is still we'd probably be most effective in having smaller (but still public) video meetings on focused topics

one thing that came up while we were discussing this was https://gitlab.com/fedora/bootc/tracker/-/issues/34, which could be a good topic

So the short answer from my side is "no" I guess?

basically, people/variants are going to want to pin to images, and that requires tags, which snowballs into having a GC strategy

basically, people/variants are going to want to pin to images and bump via CI, and that requires tags, which snowballs into having a GC strategy

Where is the video stream? Here for the first time ime with the element Android app.

!hi

sorry I'm late

Robert, at some point we switched to text by default, and video as needed

But I'm happy to do as Colin mentioned, and have video meetings on specific topics -- we just need to program those

If Konflux pushes tagged releases and not just latest then that should help us a lot

correct. I'd say we don't do video unless we have a specific topic we want to discuss in that video meeting

organizing those topics is the extra muscle we need though

ok, https://quay.io/repository/centos-bootc/centos-bootc?tab=tags is unusable

mmartinv: is this something you'd be interested to do as a follow-up to the initial pipeline work?

so we need to make sure that the tags pushed by Konflux are usable

travier: that's just SBOM/attestation stuff, i don't think it's expected to be used by users directly, but rather e.g. cosign AIUI

I am trying to figure out what the release pipepeline is supposed to do

i.e. those aren't historical tags

A well-known tagging scheme would have been great

Just after the base image refactor, we needed to pin to an earlier build while we worked through some issues, which was more difficult than it should have been. You don't know which are Stream9 or Stream10, the arches force us to search through many pages etc.

Yeah, this would certainly help out a lot.

I am trying to figure out what the release pipeline is supposed to do

Jonathan Lebon: I don't see any tagged version in the repo beyond the c9s/c10s tags

Just after the base image refactor, we needed to pin to an earlier build while we worked through some issues, which was more difficult than it should have been. You don't know which are Stream9 or Stream10, the arches force us to search through many pages etc.

Yeah, this would certainly help out a lot.

A well-known tagging scheme would have been great so we don't _need_ to try and navigate the digests

https://quay.io/repository/fedora/fedora-coreos?tab=tags&tag=latest could be a good example to follow

For reference, what this should look like: https://quay.io/repository/fedora/fedora-coreos?tab=tags

We can add a tags based on timestamp I believe

yeah, they're missing there too. i thought you maybe thought that those were it but used a sha for a weird reason

It's worth noting here the fedora-coreos one looks pretty by default because it's not sigstore-signed

the sigstore signatures are hidden by default in quay from memory

Right. I think currently that's how it's done until the referrers API stuff is more widespread? (At least that's how I understand it)

https://quay.io/repository/fedora-ostree-desktops/silverblue?tab=tags (with some signed/some unsigned)

Hmm I think a sub-decision here (was this made already) is whether to have konflux push directly or indirect through that cloud-image-uploader thing

Hmm I think a sub-decision here (was this made already?) is whether to have konflux push directly or indirect through that cloud-image-uploader thing

I personally think it's weird and awkward to wedge containers and disk images into the same tool, though I understand how we got here

It's probably going to happen in two steps: push to a "ci/testing/Staging" repo first, run the tests, then push to official repo

Colin Walters: are you talking about bootc ?

Colin Walters: are you talking about bootc ?

that was sarcasm, ignore me

? bootc doesn't do anything with disk images except `install to-disk` which is just a simple stub reference

- latest-standard

travier: the current release plan is

``` value:

- name: fedora-bootc-rawhide-minimal

repository: quay.io/fedora-testing/fedora-bootc

tags:

- '{{ git_sha }}'

- '{{ git_short_sha }}'

- rawhide-minimal-{{ timestamp }}

- rawhide-minimal

- latest-minimal

- name: fedora-bootc-rawhide-tier-x

repository: quay.io/fedora-testing/fedora-bootc

tags:

- '{{ git_sha }}'

- '{{ git_short_sha }}'

- rawhide-tier-x-{{ timestamp }}

- rawhide-tier-x

- latest-tier-x

- name: fedora-bootc-rawhide-standard

repository: quay.io/fedora-testing/fedora-bootc

tags:

- '{{ git_sha }}'

- '{{ git_short_sha }}'

- rawhide-standard-{{ timestamp }}

- rawhide-standard

```

Not sure how that would happen in Fedora infra however regarding pushing to official repos

Just a proposal of course

Each image should have it's own repo

travier: i guess this is for staging it first though. maybe it doesn't really matter at that point

(so no suffix)

sure, but then you need to map the tags, etc.

ideally we use a tagging scheme that is similar to the one used for Fedora composes: https://openqa.fedoraproject.org/nightlies.html

mmartinv: what's the timestamp format?

This discussion strongly relates to https://gitlab.com/fedora/bootc/base-images/-/merge_requests/150

travier: was thinking that. i think it'd be great if we actually matched the exact compose ID we built from

The argument here is OCI already *has* a standardized timestamp embedded so it's weird to replicate a possibly different timestamp in a version

rpm-md repositories *also* have a timestamp in the XML that's not widely used and the compose datestamps kind of duplicate, but also prefix with a major

i wanted to do this for RHCOS/SCOS things actually, but the glue code for it is awkward

We are doing this today in the centos-bootc/rhel-bootc pipelines note

Jonathan Lebon: not sure, I wasn't able to release anything yet

sorry, my "this" in my sentence was "use pungi IDs". is that the same as your "this"?

the datestamp we use in FCOS versioning is the datestamp from most recent repo update

the datestamp we use in FCOS versioning is the date from most recent repo update

the datestamp we use in FCOS versioning is the date from most recent repo update for the lockfiles we use as input

Jonathan Lebon: https://gitlab.com/redhat/centos-stream/containers/bootc/-/blame/c10s/Containerfile?ref_type=heads#L24

Though on this whole topic, one thing I hope to do and would transform this whole discussion is https://github.com/rhinstaller/anaconda/discussions/5888 - because it would mean we must build a container as part of a compose, instead of having two different things awkwardly glued together

i.e. https://github.com/coreos/fedora-coreos-config/blob/2b082ce759025195f4e8a090f412479b8cbad6d0/manifest-lock.x86_64.json#L2648

Does that still make sense in a world where FCOS derives from fedora-bootc?

OK nice. I like that actually.

(I _don't_ like though the major bot spam that comes with it. Ideally it'd push to a side branch so tests run there, and then directly pushes to the main branch quietly if it passes)

probably.. depends on how we lock the additional content we add on top

i think we should reflect the fedora-bootc version, but yeah, we'd want an extra field for our bits on top

did we decide whether we'd use renovate on fedora-bootc too or not yet?

because that also ties into this

Ideally we would not, otherwise that means that we re-add lockfiles?

I feel pretty strongly I want to align fedora-bootc and centos-bootc and not treat them as decoupled

So that would imply using renovate in fedora-bootc yes, unless we come up with something else that can also be deployed in centos-bootc

Yes...though I feel pretty strongly the real solution to this is to do base image builds and "composes" together and not separately

Do you mean doing bootc image builds during Fedora composes?

My hot take on this is that ideally we _don't_ have lockfiles because we have solid gating at the Bodhi level, but until we have that, we kinda need lockfiles.

have to drop for another meeting. ttyl!

one of the things CoreOS does today which I feel pretty strongly is a value add is that we don't ship *ANYTHING* unless tests pass. If you bake the bootc image build into the base composes you will lose that.

It's a subtle detail, but I think it's important.

I am new to bootc and still quite new to fedora. For my idea https://eu-os.gitlab.io I use currently blue-build.org which doesn't yet offer bootc. My goal is to build a distro leveraging container pipelines as much as possible. It should have FDE integrating with the TPM and optionally U2F/FIDO.

If you have any cool bits to share for this work, please let me know.

Not just that but actually making Anaconda (the ISO) *derive* from fedora-bootc so we need to build a chain of containers

Agree. If bootc-image-builder supported that, we would be using it already :)

https://github.com/travier/fedora-kinoite/blob/main/fedora-kinoite-live/Containerfile

(It's how I did the LiveISO using kiwi)

Hi Robert, thanks for sharing! We today have a list of downstream distro/OS only in bootc upstream but we should probably land one somewhere in the https://gitlab.com/fedora/bootc/docs perhaps? If you run into any bugs or issues don't hesitate to reach out!

OK so...a whole lot was discussed here on the releng side. I think we have trackers for *most* of it. I will file one around fedora-bootc and versioning.

mmartinv: Thanks for the work you're doing and I am ready to help too with anything needed on this

Did we have anything else?

Sounds like we can close this one off

Sorry for my divided attn!

I read that universal blue is more aligned on containers already than the fedora atomic desktops. Is fedora to swith anytime soon?

Robert: The roadmap is at https://gitlab.com/fedora/ostree/sig/-/issues/26

And all our progress will automatically benefit universal blue 🙂

OK, I'll close it off, thanks everyone!

#endmeeting