Bug 1889919 - Document correct way to fetch cluster version
Summary: Document correct way to fetch cluster version
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: OLM
Version: 4.6
Hardware: All
OS: All
Target Milestone: ---
: ---
Assignee: Evan Cordell
QA Contact: Jian Zhang
Depends On:
TreeView+ depends on / blocked
Reported: 2020-10-20 22:39 UTC by Chris Johnson
Modified: 2020-10-21 18:16 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-10-21 18:16:04 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Chris Johnson 2020-10-20 22:39:16 UTC
Description of problem:

It's not clear how operators can detect which version of OCP is currently installed.  There are use cases where the operator's web hook would like to behave differently or block CR requests depending on the version of OCP itself.

I see that `oc version` invokes: 

However, it seems like the official location is the ClusterVersion version object.  However, it's not clear how to correctly parse that object.

We found this:

But it doesn't explain how to programmatically parse the Cincinnati object properly.

Expected Results:
I would like some documentation with examples on how to properly identify the version of OCP that's running.

Comment 1 W. Trevor King 2020-10-20 23:21:54 UTC
"the version of OCP that's running" isn't a well-defined thing.  Some more discussion in bug 1692670.  I'm closing this bug as a dup of that one, but feel free to re-open if you want space to talk specifically about your particular operator/webhook use-case.

*** This bug has been marked as a duplicate of bug 1692670 ***

Comment 2 Chris Johnson 2020-10-21 13:04:22 UTC
We have an operator that will/should not run on OCP <=4.5 (require 4.6 and above because of various reasons... it's tested, it's EUS, has many features we need, etc) and want to support only running OCP >=4.6.

We can enforce this limitation multiple ways.  
1.  We could limit the install of the Operator on 4.5 by splitting the catalogs into two or more.  We would need some way of keeping our CatalogSources image references in sync with the OCP version (when OCP is upgraded), which means we also need a way of determining what version OCP is running.
2.  We could prevent the operator pod from starting if the OCP version is not valid.  We would need a way of determining the OCP version, and this would be a horrible user experience.
3.  We could update our WebHook to prevent creating CRs (operands) for the operator, or provide a status message in the CR why it's not valid.  We again need a way of determining the OCP version programmatically.

In parallel we are working with OLM to see if we can figure out how to encompass arbitrary metadata into the Operator to identify labels that are installable.  But this will take time.  We need some sort of solution today for all existing 4.x versions of OCP.

So, I'm really asking what is the preferred/supported way of programmatically detecting what version of OCP is currently running with the functionality that is in OCP today?

Comment 3 W. Trevor King 2020-10-21 17:32:52 UTC
> ...require 4.6 and above because of various reasons...

Can't you just test for those dependencies?  If they happen to exist on a nominally-4.5 cluster, say, because the cluster is very late in a 4.5 -> 4.6 update, then great :).

Comment 4 Scott Dodson 2020-10-21 17:52:32 UTC
After discussing with the OLM team they indicate that minKubeVersion is the proper way to assert a minimum cluster version for operator installation. With respect to anything more fine grained than that then they suggest testing for presence of required APIs and versions on an API by API basis. Paying close attention to the clusterversion object is not an API we intend to support.

I'm moving this to the OLM component as they define the patterns here.

Comment 5 Kevin Rizza 2020-10-21 18:16:04 UTC
Without any explicit support for checking OCP cluster version, this doesn't appear to be a bug. Operators should prefer to make decisions on a cluster based purely on a combination of minKubeVersion and, when running, examining what APIs are available on the environment.

Closing this as NOTABUG. If a feature like this is truly required and there's some gap here, a feature request should be filed against the component that owns the OpenShift version (so that it can be debated on its merit as something to include in a future version).

Note You need to log in before you can comment on or make changes to this bug.