Add (and use) full version label to ClusterDeployment#2084
Conversation
Our clusterversion controller creates labels on the ClusterDeployment
based on the spoke cluster's `clusterversion version` object's
`status.desired.version` string. However, previously we were using
`semver` to parse that string and reporting only the major, minor, and
patch numerals, e.g.
```
"hive.openshift.io/version-major": "4",
"hive.openshift.io/version-major-minor": "4.14",
"hive.openshift.io/version-major-minor-patch": "4.14.0"
```
In cases where the clusterversion is pre-release, this lacks the
pre-release information.
This commit adds a new label containing the full, un-parsed version
string from clusterversion, e.g.
```
"hive.openshift.io/version": "4.14.0-ec.4"
```
We also cut over all the internal code paths that used to use the
major-minor-patch label for version checking, as the full string will
always be more accurate, particularly when determining whether we're
before or after a version containing specific functionality.
The other external-facing effect is in the tabular output of `oc get
cd`, which now reports the full version string rather than the
major-minor-patch string. For GA-level clusters, this will be identical;
it will only differ (being more precise) for pre-release clusters.
HIVE-2293
openshift-ci
Bot
added
the
approved
|
/assign @suhanime |
| - jsonPath: .metadata.labels.hive\.openshift\.io/cluster-region | ||
| name: Region | ||
| type: string | ||
| - jsonPath: .metadata.labels.hive\.openshift\.io/version-major-minor-patch |
There was a problem hiding this comment.
Are we completely sure no one uses this label before we remove it? From what I understand, the practice is to keep both and let the user decide which one they want to use
There was a problem hiding this comment.
We’re not removing the label, just changing which label we use in oc get cd
There was a problem hiding this comment.
To expand a bit: 99% of clusters (and 100% of prod clusters, since they should only be using GAed releases) will have the same value here before & after.
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #2084 +/- ##
==========================================
+ Coverage 57.38% 57.52% +0.13%
==========================================
Files 186 186
Lines 25712 25856 +144
==========================================
+ Hits 14756 14874 +118
- Misses 9717 9734 +17
- Partials 1239 1248 +9
|
|
/test e2e-pool claim deletion hung: improving artifact gathering via #2086. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: 2uasimojo, suhanime The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@2uasimojo: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
3 participants
Our clusterversion controller creates labels on the ClusterDeployment based on the spoke cluster's
clusterversion versionobject'sstatus.desired.versionstring. However, previously we were usingsemverto parse that string and reporting only the major, minor, and patch numerals, e.g.In cases where the clusterversion is pre-release, this lacks the pre-release information.
This commit adds a new label containing the full, un-parsed version string from clusterversion, e.g.
We also cut over all the internal code paths that used to use the major-minor-patch label for version checking, as the full string will always be more accurate, particularly when determining whether we're before or after a version containing specific functionality.
The other external-facing effect is in the tabular output of
oc get cd, which now reports the full version string rather than the major-minor-patch string. For GA-level clusters, this will be identical; it will only differ (being more precise) for pre-release clusters.HIVE-2293