Bug 1671953 - The minKubeVersion feature of the OLM doesn't work
Summary: The minKubeVersion feature of the OLM doesn't work
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: OLM
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ---
: 4.1.0
Assignee: Evan Cordell
QA Contact: Jian Zhang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-02-02 09:42 UTC by Jian Zhang
Modified: 2019-06-04 10:43 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-04 10:42:31 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:0758 None None None 2019-06-04 10:43:52 UTC

Description Jian Zhang 2019-02-02 09:42:54 UTC
Description of problem:
When I set the value of the minKubeVersion to "v1.12", the cluster version is "v1.12.4", the csv object state on Pending status all the time.
The csv info:
...
  Reason:                  RequirementsNotMet
  Requirement Status:
    Group:    operators.coreos.com
    Kind:     ClusterServiceVersion
    Message:  CSV version parsing error
    Name:     etcdoperator.v0.9.2
    Status:   PresentNotSatisfied
    Version:  v1alpha1

Version-Release number of selected component (if applicable):
OLM: 
 io.openshift.build.commit.id=1f312481ae3641eea471abb792f9b056206e4cf4
[core@ip-10-0-39-59 ~]$ oc version
oc v4.0.0-0.153.0
kubernetes v1.12.4+de4b0b31fd
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://jian-1-api.qe.devcluster.openshift.com:6443
kubernetes v1.12.4+f39ab668d3

How reproducible:
always

Steps to Reproduce:
1. Install the OCP 4.0
2. Create a ConfigMap/CatalogSource objects on the openshift-operators namespaces. Like below:
$ oc create -f https://raw.githubusercontent.com/jianzhangbjz/v3-testfiles/v4.0/olm/configmap/operator-minKubeVersion.yaml 
$ oc create -f https://raw.githubusercontent.com/jianzhangbjz/v3-testfiles/v4.0/olm/catalogsource/catalogsource.yaml 

3. Modify the configmap object, and change the value of the minKubeversion to "v1.12".
4, Create a subscription for this. Like below:
$ oc create -f https://raw.githubusercontent.com/jianzhangbjz/v3-testfiles/v4.0/olm/subscription/etcdoperator.v0.9.2-sub.yaml 

Actual results:
No etcd-operator pods generated. 


[core@ip-10-0-39-59 ~]$ oc get csv
NAME                  DISPLAY   VERSION   REPLACES              PHASE
etcdoperator.v0.9.2   etcd      0.9.2     etcdoperator.v0.9.0   Pending


Expected results:
The "v1.12" strings should be parsed successfully. The etcd-operator pods should be generated.

Additional info:
...
Events:
  Type    Reason               Age                  From                        Message
  ----    ------               ----                 ----                        -------
  Normal  RequirementsUnknown  10m                  operator-lifecycle-manager  requirements not yet checked
  Normal  RequirementsNotMet   5s (x50 over 9m58s)  operator-lifecycle-manager  one or more requirements couldn't be found

Comment 2 Vu Dinh 2019-02-12 05:26:35 UTC
Hi Jian,

I have merged a PR to allow the prefix "v". However, I also make it clear in documentation that we only accept standard SemVer format which is Major.Minor.Patch as minimum k8s version. The prefix "v" is preferably excluded but the code should be able to handle that prefix now. 

Thanks,
Vu

Comment 3 Jian Zhang 2019-02-12 09:48:13 UTC
Hi, Vu

Thanks for your update! It's better if we can pop-up a warning message when any non-standard format. 
You know, sometimes the users will not follow the docs seriously.

Comment 4 Vu Dinh 2019-02-12 15:43:17 UTC
Hey Jian,

The current message for this type error is "...parsing error" as you can see in "Message:  CSV version parsing error". It is not the most descriptive message but it is fine for now. I'll try to improve the message in further PRs. I don't think the current UI will pick up this error but it is something for Alec to think about perhaps.

Vu

Comment 5 Jian Zhang 2019-02-14 10:14:35 UTC
Hi, Vu

> I'll try to improve the message in further PRs. I don't think the current UI will pick up this error but it is something for Alec to think about perhaps.
It would be great if we can do this.

> I also make it clear in documentation that we only accept standard SemVer format which is Major.Minor.Patch as minimum k8s version.

One more question, for example, the "v1.12" parse error, but the "v1.12.0" works. They are the same value actually.
I was wondering if we can translate the "Major.Minor" to "Major.Minor.0" automatically, what do you suggest?

...
  Maintainers:
    Email:           support@coreos.com
    Name:            CoreOS, Inc
  Maturity:          alpha
  Min Kube Version:  v1.12
...
  Requirement Status:
    Group:    operators.coreos.com
    Kind:     ClusterServiceVersion
    Message:  CSV version parsing error
    Name:     etcdoperator.v0.9.2
    Status:   PresentNotSatisfied
    Version:  v1alpha1


  Maintainers:
    Email:           support@coreos.com
    Name:            CoreOS, Inc
  Maturity:          alpha
  Min Kube Version:  v1.12.0
  Requirement Status:
    Group:    operators.coreos.com
    Kind:     ClusterServiceVersion
    Message:  CSV minKubeVersion (v1.12.0) less than server version (v1.12.4+a532756e37)
    Name:     etcdoperator.v0.9.2
    Status:   Present

Comment 6 Vu Dinh 2019-02-14 14:23:36 UTC
Hey Jian,

I'm aware of that behavior as it is expected. The semantic versioning specification is strict and expect the version to be dotted-tri format AKA 1.0.0 even if it is zero.
Here is the reference: https://semver.org/#spec-item-2. I will try to make another PR to add more details to the message field so users can identify the issue more easily.

Thanks,
Vu

Comment 8 Jian Zhang 2019-02-19 09:14:59 UTC
Vu,

> Here is the reference: https://semver.org/#spec-item-2. I will try to make another PR to add more details to the message field so users can identify the issue more easily.

Thanks for your information! It would be great if we can provide more error info or forbidden this kind of behavior. Could you post the related PR in here?

Comment 9 Vu Dinh 2019-03-08 14:08:39 UTC
Hi Jian,

There is a recently merged PR [1] to add validation to minKubeVersion field on the template. So the validation will check for standard SemVer and also accept starting "v" even though it is not standard SemVer format. So there should be  failure on validation side before it even hits the backend code.

[1] https://github.com/operator-framework/operator-lifecycle-manager/pull/739

Comment 10 Jian Zhang 2019-03-11 02:31:16 UTC
[jzhang@dhcp-140-18 ocp-09]$ oc get clusterversion
NAME      VERSION                             AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.0.0-0.nightly-2019-03-06-074438   True        False         35h     Cluster version is 4.0.0-0.nightly-2019-03-06-074438

OLM commit info:
               io.openshift.build.commit.id=04d2513ec9932f20bec57456ba9b4deebd733f71
               io.openshift.build.commit.url=https://github.com/operator-framework/operator-lifecycle-manager/commit/04d2513ec9932f20bec57456ba9b4deebd733f71
               io.openshift.build.source-location=https://github.com/operator-framework/operator-lifecycle-manager
The fixed PR not merged in this payload, change status to MODIFIED.

Comment 12 Jian Zhang 2019-03-15 02:58:03 UTC
I can see the warning when I input the wrong "v1.12" strings. LGTM, verify it.
OLM info:
               io.openshift.build.commit.id=840d806a3b20e5ebb7229631d0168864b1cfed12
               io.openshift.build.commit.url=https://github.com/operator-framework/operator-lifecycle-manager/commit/840d806a3b20e5ebb7229631d0168864b1cfed12
               io.openshift.build.source-location=https://github.com/operator-framework/operator-lifecycle-manager

Cluster version: 4.0.0-0.nightly-2019-03-13-233958

Comment 14 errata-xmlrpc 2019-06-04 10:42:31 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:0758


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