owned this note   changed 4 years ago  
Published Linked with GitHub

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:

INFO

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

Action items from last meeting

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

Platform Request: Nutanix AOS with AHV

Any other topics? Fedora CoreOS Goals

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
Select a repo