Bug 1671948 - ConfigMap pod crashed due to the type conversion
Summary: ConfigMap pod crashed due to the type conversion
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: OLM
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
medium
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:21 UTC by Jian Zhang
Modified: 2019-06-04 10:43 UTC (History)
2 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:21:04 UTC
Description of problem:
Get the below errors when setting the value of the "minKubeVersion" to 1.13
[core@ip-10-0-39-59 ~]$ oc get pods
NAME                                         READY   STATUS             RESTARTS   AGE
installed-community-global-operators-xk2z9   0/1     CrashLoopBackOff   2          40s
[core@ip-10-0-39-59 ~]$ oc logs installed-community-global-operators-xk2z9 
time="2019-02-02T09:09:56Z" level=info msg="Using in-cluster kube client config"
time="2019-02-02T09:09:56Z" level=info msg="loading CRDs" configmap=installed-community-global-operators ns=openshift-operators
time="2019-02-02T09:09:56Z" level=info msg="loading Bundles" configmap=installed-community-global-operators ns=openshift-operators
Error: json: cannot unmarshal number into Go struct field ClusterServiceVersionSpec.minKubeVersion of type string
Usage:
   [flags]

Version-Release number of selected component (if applicable):
OLM: 
 io.openshift.build.commit.id=1f312481ae3641eea471abb792f9b056206e4cf4
ConfigMap:
quay.io/operatorframework/configmap-operator-registry:latest

How reproducible:
always

Steps to Reproduce:
1. Install the OCP 4.0
2. Create a configmap/catalogsource objects under 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, and change the value of the "minKubeVersion" to 1.13
4, Create a subscription, like below:
$ oc create -f https://raw.githubusercontent.com/jianzhangbjz/v3-testfiles/v4.0/olm/subscription/etcdoperator.v0.9.2-sub.yaml 

Actual results:
Got errors:
[core@ip-10-0-39-59 ~]$ oc get pods
NAME                                         READY   STATUS             RESTARTS   AGE
installed-community-global-operators-xk2z9   0/1     CrashLoopBackOff   2          40s
[core@ip-10-0-39-59 ~]$ oc logs installed-community-global-operators-xk2z9 
time="2019-02-02T09:09:56Z" level=info msg="Using in-cluster kube client config"
time="2019-02-02T09:09:56Z" level=info msg="loading CRDs" configmap=installed-community-global-operators ns=openshift-operators
time="2019-02-02T09:09:56Z" level=info msg="loading Bundles" configmap=installed-community-global-operators ns=openshift-operators
Error: json: cannot unmarshal number into Go struct field ClusterServiceVersionSpec.minKubeVersion of type string
Usage:
   [flags]


Expected results:
The configmap-server should handle the type conversion.

Additional info:

Comment 1 Jeff Peeler 2019-02-05 18:43:46 UTC
I'm not really sure this is a bug. The expected version format is of the form "x.x.x", for example 1.13.0. If you must use a less precise format (I suppose 1.13 could be interpreted as 1.13.0), then just quote the version number in the configmap, like:

minKubeVersion: '1.10'

Comment 2 Jian Zhang 2019-02-09 12:08:45 UTC
Jeff,

> The expected version format is of the form "x.x.x", for example 1.13.0.

Yes, thanks, I know. But, it would be better if it can compatible with something characters like `minKubeVersion: test-v1.xx`.

Comment 3 Vu Dinh 2019-02-12 05:23:42 UTC
Hi Jian,

As Jeff mentioned above, the minimum k8s version will be Major.Minor.Patch (all integers) format which is standard SemVer format. I have merged a PR to allow the prefix "v" just in case users may add that. However, we will not accept any non-standard format or characters. Please use valid format to test the code.

Thanks,
Vu

Comment 4 Jian Zhang 2019-02-12 09:43:13 UTC
Hi, Vu

> However, we will not accept any non-standard format or characters.

Thanks for your information. So does it pop-up a warning when typing the non-standard format to the csv?
Actually, I haven't seen any warnings or forbidden. Correct me if I'm wrong.

Comment 5 Evan Cordell 2019-02-18 17:03:08 UTC
Crashing is the expected behavior when invalid csvs are included in a catalog.

Comment 6 Jian Zhang 2019-02-19 09:05:31 UTC
Evan, Vu

Yes, I know, we should fill in the standard format.
But, for the users, they may input a variety of formats even if we highlight this in the release document.
So, it's better if we can pop-up the forbidden info before they saving the wrong format.

Comment 7 Jian Zhang 2019-03-11 02:36:29 UTC
> So, it's better if we can pop-up the forbidden info before they saving the wrong format.

Fixed PR in bug 1671953 comment 9, hasn't been merged in the current payload, change Status to MODIFIED.
[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

Comment 9 Jian Zhang 2019-03-15 03:03:57 UTC
I can see the warning now, 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 11 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.