---
# System prepended metadata

title: 20230126-discuss-FCOS-update-graph-in-container-world

---

# 20230126-discuss-FCOS-update-graph-in-container-world

## Option 1 - Use tags

- https://github.com/coreos/fedora-coreos-tracker/issues/1263#issuecomment-1192631773
- graph encodes tags
- layering users are required to rebuild all our images using the same tag name
    - or maybe there is a label that could be used instead that maps back to the FCOS this container was derived from.

### Option 1a - Use version tags for non-derivation

But derivation cases we just track whatever requested tag is there and ignore upgrade graphs
and if things break it's the user's fault (for now).

### Option 1b - ostree.endoflife-rebase

Barriers are manifested as tags - most obviously implemented corresponding to "major versions"
e.g. Fedora 36, 37 and RHEL 9.1, 9.2.  Metadata injected into container image metadata that
says for e.g. quay.io/fedora/oscore:36 to switch to quay.io/fedora/oscore:37 later.  This
metadata would only be 

## Option 2 - Dismantle Cincinnati graph

- https://github.com/coreos/fedora-coreos-tracker/issues/1263#issuecomment-1397650636 and onward
- stop using cincinnati
- update system follow single tag
- have a proxy registry (e.g. `registry.updates.fedoraproject.org`) for re-implementing rollout period and stopping rollouts

## Option 3 - throw some JSON/YAML/TOML/HCL/XML?/ASN.1?? in S3

- As a user, not deriving container images
    - things should work as today (no user facing changes)
- As a user, deriving container images, but no need for more control over rollout/etc
    - user does not need to create their own json (accessible via https)?
    - the client IDs the base FCOS version that is the target of current upgrade
        - find related container image in user's defined repo via tags/labels?
- As FCOS, scheduling a rollout
- As FCOS, stopping a rollout

- json file on the side to stop rollouts
    - also possibly control deadends/barriers
        - denylist upgrading from 35.*
        - deadend 36.20230111.1.0
        - by default update to latest
- no update server
- put in place some policy for timing out systems to update
    - generation based

```yaml!

rollouts:
  - target: 1.2.3.4
    start: <time>
    duration: <duration>
#barriers:
deadends:
  - "37.2.3.4" # do not upgradea

src:
  # barrier
  "< 36": "barrier-tag"
  ">= 36.0.1.2, < 36.1.2.3": "barrier-2"
  # deadend
  "< 35": ~
deny:
  - "37.2.3.4"
```

"{fedoraver}-{fcos-ver} > 37.1.2.3"


# Related topics

https://major.io/p/watchtower/ for container images


## Current controls that exist

- server side controls
  - deadends
  - barriers
  - rollout window start/duration
- fleet controls
  - reboot coordination
- client side controls
  - periodic window (control when reboots happen and updates are applied)
  - systemd reboot inhibitors also block rebooting for updates (and other reasons)
- checks
  - Zincati doesn't rerun an upgrade that's been rolled back

## Proposed Future Controls

- server side controls
  - deadends
  - barriers
  - rollout window start/duration
- client side controls
  - periodic window (control when reboots happen and updates are applied)
  - systemd reboot inhibitors also block rebooting for updates (and other reasons)
  - rollout window start/duration?
  - overriding rollout to upgrade immediately
  
## Lightweight layering (containers, git repos, tarballs?)

- https://github.com/containers/bootc/issues/22 
- layers are lightweight files and get applied client side
- OS updates still follow canonical locations for the OS updates