# 20211103_Fedora-CoreOS-Virtual-Meeting

location: https://meet.google.com/igd-ekxw-nzi

### Agenda

#### Roll Call

Add your name and involvement/interest in FCOS here:

- Dusty Mabe - [e-mail] - FCOS/RHCOS team at Red Hat
- Colin Walters - [e-mail] - RHT CoreOS team
- Jan Kuparinen - [e-mail]
- Jonathan Lebon - [e-mail] - FCOS/RHCOS team
- Jaime Magiera - [e-mail] - University of Michigan
- Michael Nguyen - [e-mail] - FCOS/RHCOS team
- Luca Bruno - [e-mail]
- Joseph Marrero - [e-mail] - FCOS/RHCOS team
- Renata Ravanelli - [e-mail] FCOS/RHCOS team
- Neal Gompa - [e-mail] - KDE SIG / OKD WG
- Benjamin Gilbert - [e-mail] - FCOS/RHCOS team

#### INFO

- FYI - `testing` stream planned to be rebased to Fedora 35 content next week

#### Action items from [last meeting](https://meetbot-raw.fedoraproject.org/teams/fedora_coreos_meeting/fedora_coreos_meeting.2021-10-27-16.27.txt)

* dustymabe to write docs for rpi4 including updating EEPROM
- DWM: draft PR for documentation on updating EEPROM
- https://github.com/coreos/fedora-coreos-docs/pull/336

#### enhancements: Propose CoreOS layering
- presented by Colin Walters
- link: https://github.com/coreos/enhancements/pull/7
- Notes:
- This proposal builds on a previous proposal. Taking what we're doing with OSTREE and using container storage to store the OSTree commits. Updates come over the wire from a container registry.
- Everything that exists today with FCOS will continue to work. This is just an alternative optional feature.
- The core change in the proposal:
- History: we've had friction with users at times over what should be in the base OS
- What if we thought of Fedora CoreOS as a base image (like in containers)
- Uses Dockerfile workflow
- Creates a layer that can then be used as your Host OS
- Package layering exists but has some drawbacks
- requires the thing you're adding to be an RPM
- JMC: If I'm booted from that generated image will I get updates for the base layer?
- No, when you build this image you become responsible for building your derived image.
-
- JL: we want to improve the package layering and other rpm-ostree operations to be able to apply them on first boot seamlessly
- DWM: Could we make the built container images happen client side so we just apply it on top when a new update comes in.
- i.e. just like package layering is done today
- DWM: what happens to the update graph if someone is following quay.io/foo
- we would need to do some work to enable this
- DWM: can I run this container (podman run), would I want to?
- in order for Dockerfile/Containerfile layering to work you must be able to run things inside the container, so it must be able to run and feel like a container that you can run in a container runtime
- JL: now you can configure the OS via a container or Ignition, this gets a little messy.
- DWM: could we re-use this for server side layering stuff?
- we could use this workflow to create derivatives and export them back into our hosted fedora ostree repository
- CW: if you create tooling that splits the OS contents into separate chunks we can get more efficient downloads from OCI registries

#### Platform Request: VirtualBox
- link: https://github.com/coreos/fedora-coreos-tracker/issues/1008
- Notes:

#### Platform Request: Nutanix AOS with AHV
- link: https://github.com/coreos/fedora-coreos-tracker/issues/1007
- Notes:

#### Any other topics? [Fedora CoreOS Goals](https://hackmd.io/h3qv7mn4RDKd_n50ANdqxw)

#### Open Floor

- NG: kinoite is an rpm-ostree based deliverable
- NG: we can't deliver kinoite as a live ISO (at least with existing Fedora releng tooling)
- NG: without a live ISO it's hard to tell people what to use as a rescue environment
- CW: FCOS uses a live ISO today, so it's possible