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
Fixed in https://github.com/operator-framework/operator-lifecycle-manager/pull/699
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
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.
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
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 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 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
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
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?
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
[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.
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
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