Repository navigation
Upgrade Graph release channel filtering ineffective #2268
Description
Describe the bug
when consuming updates through https://origin-release.ci.openshift.org/graph or subgraphs, setting a release channel such as stable-4 does not affect the releases provided.
using the releasestream-names (such as 4-scos-stable) does not work, since calling https://origin-release.ci.openshift.org/graph?channel=4-scos-stable errors out with Unsupported ?channel, must be '', 'prerelease', 'prerelease-*', 'nightly', 'nightly-*', 'stable', or 'stable-*.
Version
No response
Reproducibility
consume updates from ci release graph
Log Bundle
No response
Activity
Prashanth684 commentedon Nov 5, 2025
Right, so the channel names need to be reversed -
4-scos-stableshould bestable-scos-4and that should work.jatinsu commentedon Nov 24, 2025
Closing this issue as it seems to been solved
rezemble commentedon Nov 25, 2025
How is this resolved? The issue has not been addressed at all.
Even if reversing the channel names as @Prashanth684 wrote (which I already addressed in the initial issue), the output is identical (apart from the sorting changing with every request, but that's a different issue altogether) to one with no filter set at all.
https://origin-release.ci.openshift.org/graph
https://origin-release.ci.openshift.org/graph?channel=stable-scos-4
please reopen? @jatinsu
Edit: same goes for the alternate fqdn https://amd64.origin.releases.ci.openshift.org/graph?...
rezemble commentedon Nov 25, 2025
Example:
I set the filter to
stable-scos-4, I expect only versions fromhttps://amd64.origin.releases.ci.openshift.org/#4-scos-stable
to be supplied - however, the graph contains all unfiltered versions, including prereleases, and their upgrade paths, causing a cluster configured with it to always suggest the latest pre-release as the current update, meaning a cluster updated to the latest stable will always show available updates.
(and, for completeness, as noted in the original issue: using the original ci channel name
4-scos-stableas the channel name does not work since the mentioned error is thrown)jatinsu commentedon Nov 25, 2025
Sorry for closing the issue, I assumed that since there hasn't been any movement in 3 weeks that the issue was resolved.
This is actually intended. See: https://github.com/openshift/release-controller/blob/83c402729afe9d08b5774029800022daa1379c9f/cmd/release-controller-api/http_upgrade_graph.go#L60-L78. This is the source code for the release controller and it filters the releases for Cincinnati, it doesn't only provide it with releases of the channel you provide. Cincinnati is our upgrade protocol and is designed this way. You can see more about the design of Cincinnati here.
This is due to OKD not using a Cincinnati graph server. This is a ongoing effort and currently we are looking into asking the fedora infra team to host the graphs
rezemble commentedon Nov 25, 2025
@jatinsu - thanks for the clarification!
release-controllersounds like a generic openshift component, not limited to okd? or is it okd specific? (I unfortunately can't test locally without some effort to get release infra up and running on one of my clusters - lack of setup know how on my part - so this is logic that just operates on crs in the ci cluster? the jira issue seems stale - is there any work that can actively be done to support you there? I'd assume the PoC to be expired or outdated?)jatinsu commentedon Nov 26, 2025
You're correct, it's not limited to okd, Openshift uses it as well.
I want to say yes? I'm a bit confused on what you're asking here. Are you asking how the release controller works?
Not as of now, there has already been a PR merged into the release pipeline to add support for Cincinnati Graphs and we're just looking towards hosting the Cincinnati graphs. Thanks for offering though!