From dc23a28e8a8ddf71b1fa4a56e40321cfbb7168db Mon Sep 17 00:00:00 2001 From: Jatin Suri Date: Fri, 18 Sep 2026 17:19:16 -0400 Subject: [PATCH 1/2] Adding cincinnati blog post --- blog/2026/09-18-okd-cincinnati.md | 98 +++++++++++++++++++++++++++++++ blog/authors.yml | 7 +++ 2 files changed, 105 insertions(+) create mode 100644 blog/2026/09-18-okd-cincinnati.md diff --git a/blog/2026/09-18-okd-cincinnati.md b/blog/2026/09-18-okd-cincinnati.md new file mode 100644 index 0000000..174e10c --- /dev/null +++ b/blog/2026/09-18-okd-cincinnati.md @@ -0,0 +1,98 @@ +--- +title: "OKD Now Has Its Own Update Service: Announcing OKD Cincinnati" +authors: ["jatinsu"] +date: 2026-09-18 +--- + +**TL;DR:** OKD is switching to its own Cincinnati update service at `updates.okd.io` — switch a cluster over with: + +```sh +oc patch clusterversion version --type merge \ + -p '{"spec":{"upstream":"https://updates.okd.io/api/updates/graph","channel":"stable-5.0"}}' +``` + +OKD clusters now have a dedicated update service. **OKD Cincinnati** is live at +[updates.okd.io](https://updates.okd.io) and serves update graphs to OKD/SCOS clusters over the +same Cincinnati update protocol that OpenShift clusters have used for years. + + + +Until now, OKD relied on the release controller to create upgrade edges — something it was never +really built to do. That caused a number of problems, from +[`ec` versions leaking into stable channels](https://github.com/okd-project/okd/issues/2315) to the +[inability to block already-accepted releases](https://github.com/okd-project/okd/issues/2348). +Cincinnati fixes these issues while simplifying over-the-air (OTA) updates. + +## What is Cincinnati? + +Cincinnati is the update service behind OpenShift's OTA upgrades. It builds a graph of releases +and the valid upgrade edges between them, then serves the slice of that graph relevant to your +cluster's channel and architecture. It has two components: + +- a **graph-builder**, which scrapes release payloads and secondary metadata to assemble the graph, and +- a **policy-engine**, which filters that graph per request (by channel and architecture) and serves it to clusters. + +## What's different for OKD's Cincinnati instance + +OKD Cincinnati runs the same upstream [openshift/cincinnati](https://github.com/openshift/cincinnati) +code, but every data source points at the OKD world instead of OpenShift: + +- **Release payloads** are scraped from `quay.io/okd/scos-release` (SCOS builds), not `ocp-release`. +- **Graph data** comes from [okd-project/cincinnati-graph-data](https://github.com/okd-project/cincinnati-graph-data), + the community-owned repository of channels and upgrade risks. + +## Channels available today + +At launch, OKD Cincinnati serves three channels: + +| Channel | Covers | +| --------------- | -------------------- | +| `stable-4.22` | 4.21 → 4.22 | +| `stable-5.0` | 4.22 → 5.0 | +| `candidate-5.0` | 4.22 `ec` → 5.0 `ec` | + +Each stable channel carries the prior minor plus its own, so you always have a supported path onto +the next release. The `candidate-5.0` channel carries pre-release (`ec`) builds if you want to test +what's coming before it lands in stable. + +## Upgrade risks, handled + +Not every build is safe to upgrade into, and OKD Cincinnati handles that the same way OpenShift does +— through **blocked edges**. For example, `4.22.0-okd-scos.4` through `.6` are blocked because CRI-O +1.36.1 could hang during node shutdown and wipe the image store on reboot; the graph steers clusters +around those builds and onto `scos.7+`, where the issue is fixed. Risks are declared in the graph-data +repo and carried forward automatically until a fix ships. + +## Built to be boringly reliable + +The service runs on the AppSRE platform across stage and production, with autoscaling, a +PodDisruptionBudget, Prometheus alerting, and SLOs for availability, error rate, and latency +(policy-engine p90 under 3 seconds). Early load testing against stage was comfortable — p90 latency +held around 19 ms up to 1,000 requests per second, roughly a 150× margin under the latency SLO — and +the load test now re-runs automatically after every stage deploy. + +## Pointing your cluster at it + +To receive updates, set your cluster's upstream to the OKD graph endpoint and pick a channel: + +```sh +oc patch clusterversion version --type merge \ + -p '{"spec":{"upstream":"https://updates.okd.io/api/updates/graph","channel":"stable-5.0"}}' +``` + +Available updates will then show up as usual: + +```sh +oc adm upgrade +``` + +:::note +Starting with OKD 5.1, clusters that aren't using OKD Cincinnati will start showing an +informational alert suggesting you switch over. The cluster-version operator won't change your +update service for you — it simply lets you know. See +[cluster-version-operator#1466](https://github.com/openshift/cluster-version-operator/pull/1466) +for the details. +::: + +Special thanks to Red Hat's OTA and AppSRE teams for helping us onboard and for hosting our service. +Point a cluster at [updates.okd.io](https://updates.okd.io), and let us know how it goes! diff --git a/blog/authors.yml b/blog/authors.yml index 08fa11b..f42683e 100644 --- a/blog/authors.yml +++ b/blog/authors.yml @@ -39,3 +39,10 @@ pskrbasu: socials: github: pskrbasu linkedin: pskrbasu +jatinsu: + name: Jatin Suri + title: Red Hat + url: https://github.com/jatinsu + image_url: https://github.com/jatinsu.png + socials: + github: jatinsu From 7fb038ac46d68080ce087449654a1d179dcd2ee7 Mon Sep 17 00:00:00 2001 From: Jatin Suri Date: Tue, 22 Sep 2026 11:46:16 -0400 Subject: [PATCH 2/2] Remove tldr and fix up wording --- blog/2026/09-18-okd-cincinnati.md | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/blog/2026/09-18-okd-cincinnati.md b/blog/2026/09-18-okd-cincinnati.md index 174e10c..6cedf20 100644 --- a/blog/2026/09-18-okd-cincinnati.md +++ b/blog/2026/09-18-okd-cincinnati.md @@ -4,20 +4,13 @@ authors: ["jatinsu"] date: 2026-09-18 --- -**TL;DR:** OKD is switching to its own Cincinnati update service at `updates.okd.io` — switch a cluster over with: - -```sh -oc patch clusterversion version --type merge \ - -p '{"spec":{"upstream":"https://updates.okd.io/api/updates/graph","channel":"stable-5.0"}}' -``` - OKD clusters now have a dedicated update service. **OKD Cincinnati** is live at [updates.okd.io](https://updates.okd.io) and serves update graphs to OKD/SCOS clusters over the same Cincinnati update protocol that OpenShift clusters have used for years. -Until now, OKD relied on the release controller to create upgrade edges — something it was never +Until now, OKD relied on the release controller to create upgrade edges which was something it was never really built to do. That caused a number of problems, from [`ec` versions leaking into stable channels](https://github.com/okd-project/okd/issues/2315) to the [inability to block already-accepted releases](https://github.com/okd-project/okd/issues/2348). @@ -43,12 +36,11 @@ code, but every data source points at the OKD world instead of OpenShift: ## Channels available today -At launch, OKD Cincinnati serves three channels: +At launch, OKD Cincinnati serves two channels: | Channel | Covers | | --------------- | -------------------- | -| `stable-4.22` | 4.21 → 4.22 | -| `stable-5.0` | 4.22 → 5.0 | +| `stable-5.0` | 5.0 | | `candidate-5.0` | 4.22 `ec` → 5.0 `ec` | Each stable channel carries the prior minor plus its own, so you always have a supported path onto @@ -73,7 +65,7 @@ the load test now re-runs automatically after every stage deploy. ## Pointing your cluster at it -To receive updates, set your cluster's upstream to the OKD graph endpoint and pick a channel: +To receive updates, first upgrade to 5.0.0-okd-scos.0, then set your cluster's upstream to the OKD graph endpoint and pick a channel: ```sh oc patch clusterversion version --type merge \