# 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

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