# 20240209_OSTree-Native-Container-Updates-Proposal
# Proposal:
The new updates strategy will not include an update server but it will include a client that can parse update guidance from a configured location. The update guidance can be disabled in order to instruct the client to not seek any update guidance and just use the latest from the current container image that is being followed.
The update guidance will consist of a single yaml file hosted locally or on the internet somewhere (file://, https://, docker://). The client knows how to pull the update guidance and parse it. In the update guidance we define rollouts, barriers, and deadends for each supported stream.
For Fedora CoreOS we'll store the update guidance as a single yaml file in s3 and store it as a single file in a scratch container for mirroring conveniences. These will be updated simultaneously and should always be in sync.
The file format:
```yaml!
streams:
next:
rollouts:
- version: 37.20230205.3.0
start: <time>
duration: <duration>
- version: 37.20230122.3.0
start: <time>
duration: <duration>
barriers:
"31.20200517.3.0":
reason: "https://github.com/coreos/fedora-coreos-tracker/issues/480#issuecomment-631724629"
"32.20200615.3.0":
reason: "https://github.com/coreos/fedora-coreos-tracker/issues/484"
"36.20190718.3.0":
reason: "https://github.com/coreos/fedora-coreos-tracker/issues/215"
deadends:
"30.20190715.3.0":
reason: "https://github.com/coreos/fedora-coreos-tracker/issues/215"
testing:
...
stable:
...
```
The client will fetch and read this update guidance (if configured to do so) and also inspect the currently configured registry location. It will determine if there is an update available and proceed to stage the update.
For derived OSTree native container images by default there is NO UPDATE GUIDANCE. Users who derive will follow a tag in a container registry. The users will control updates by pushing new containers on top of the tag. Optionally users of derived OSTree native container images can provide their own update guidance and employ the use of other tags in the registry to implement barriers/deadends themselves. These are the same tools FCOS employs to implement barriers/deadends.