Agenda for the Flatcar Developer Sync on Wednesday, 23th of April 2025, 2:30pm UTC

[tormath1]

In our monthly Flatcar developer syncs maintainers review development / roadmap progress, discuss special projects like OS composability, secure / trusted boot, vendor support, and CNCF incubation status. We provide an overview of ongoing work, give an outlook of future work, and plan the next release.

Join if you're curious about current or future Flatcar development and/or to raise visibility of a feature, bug, or PR.

• Jitsi Link: https://meet.flatcar.org/OfficeHours
• Youtube live stream / recording: TBD
  • All recordings: https://www.youtube.com/@FlatcarLinux/live
• Community Calls calendar (all future calls): link
  • iCal version: link

Welcome

• Brief intro/check-in of the new participants in the Jitsi call. Please introduce yourself and share what brings you here today.

News and Announcements

End of support for CGroupsV1 in early 2025

Flatcar will stop supporting the cgroups v1 backwards compatibility mode in Q1 2025.

• With our adoption of systemd-256, support for legacy CGroupsV1 will end in Alpha, Beta, and eventually Stable.
• Enabling legacy CGroupsV1 during deployment will not be supported anymore.
• Nodes that use CGroupsV1 legacy mode will fail to update. This ensures your workloads will not be disrupted. Enable CGroupsV2 on your legacy CGroupsV1 nodes in order to successfully update.
• LTS-2024 will support CGroupsV1 until late 2025.

Monthly Contributions and Advisory status Review

1. Discuss the latest Monthly Contributions Report
   • First-Time Contributors in the last month:
     • @sanjaykkr : Nebraska Alpine base image update
     • @mrbojangles3 : Add MLX5 HW offload kmod
     • @UnholyRope : keepalived sysext and general bakery improvements
     • @darkspadez: EROFS bakery support, general bakery improvements
2. Review of last month's advisory stats in the latest Contributions Report
   a. Advisory status and planning: Flatcar tactical, release planning, and roadmap (view)

Ongoing and Planned Tasks Review

Discussion

1. Roadmap review: Flatcar tactical, release planning, and roadmap (view) (@t-lo, @miao0miao )
2. Projects status review:
   a. Composable OS: sysext and ClusterAPI (@tormath1) - Flatcar tactical, release planning, and roadmap (view)
   b. SecureBoot / Trusted Boot (@sayanchowdhury ) - Flatcar tactical, release planning, and roadmap (view)
   c. CNCF Incubation process (@miao0miao) - Flatcar tactical, release planning, and roadmap (view)
   d. Flatcar infrastructure status (@tormath1) - Flatcar tactical, release planning, and roadmap (view)
   e. Nebraska status (@ErvinRacz) - Flatcar tactical, release planning, and roadmap (view)
3. Maintainer team tactical / implementation (aka "line work") status review (@sayanchowdhury): Flatcar tactical, release planning, and roadmap (view)
4. Open Mic: Work to assign / User issues and PRs to discuss?

Release Planning

• Ongoing and upcoming releases tracker: (Flatcar tactical, release planning, and roadmap (view)) (@sayanchowdhury)
• Talk about the upcoming release and the status of the packages
• Status of the ongoing release
• Preparation of the next release

Q&A

• Questions from community participants, answered by the Flatcar maintainers

Administrative tasks after meeting concluded

• Create a new Github discussion for the next Flatcar developer sync: https://github.com/flatcar/Flatcar/discussions/new?category=flatcar-developer-sync
• Close this discussion as "Resolved".

[reavessm]

I know you guys just revamped how sysexts are being built and hosted, but I wanted to hear your thoughts on proposals made by the bootc (bootc-dev/bootc#7) and dnf (rpm-software-management/dnf5#1731 (comment)) teams. It seems the bootc team wants to store their sysexts in quay (or another registry) and dnf is looking at having the dnf be a frontend for sysexts as well as distributing dnf itself as a sysext.

Can flatcar make use of sysexts built for other platforms?

Would building flatcar sysexts for an oci registry like quay allow for greater cross-pollination? I already see some overlap with the kubernetes sysexts defined here: https://github.com/travier/fedora-sysexts

Would installing the hypothetical dnf sysext make sense in testing scenarios? Say you have multiple flatcar clusters and you want to see how something would work so you install dnf on the test cluster, dnf install --sysext whatever you need, then use that to generate ignition configs for the prod cluster?

I know these are distinct projects with different goals, but I still wanted to get your thoughts. I will try to make it to the meeting next wednesday but I may only be able to watch it on YouTube and not join live, we'll see.

Thanks

[travier]

Can flatcar make use of sysexts built for other platforms?

Files included in a sysexts have SELinux labels (xattrs) that are specific to an SELinux policy. Thus you can not use Fedora sysexts on Flatcar or the reverse unless to forgo SELinux support or dynamically relabel / rebuild the sysext using the local SELinux policy before merging it (but then you kind of lose a bit of the guarantee of the sysext model).

Would installing the hypothetical dnf sysext make sense in testing scenarios?

Sysexts are additive additions via an overlay. When running on Flatcar, dnf would have no idea what packages are already installed in the image, so you would have to select manually which package to include in your sysext.

[ervcz]

Nebraska topics:

• Nebraska release 2.10.0, new contributors
• Aim to make Nebraska releases regular (i.e. 1w before each Flatcar release)
• Road map status (e2e testing, CRA to Vite migration, being on track with the dependency updates)
• MUI7 came out