Description of problem: When extracted the budle image i see below params. I see that olm.skipRange should not be set as it is the first release of the operator image, com.redhat.openshift.versions should be set according to https://docs.engineering.redhat.com/display/CFC/Delivery, here it should be as below. Also i see that there is no minkubeversion set. annotations: ... com.redhat.openshift.versions: v4.10 oc image extract registry-proxy.engineering.redhat.com/rh-osbs/secondary-scheduler-operator-metadata-rhel-8@sha256:d98a19803aaa53374950bec108221729c0f9ce8e28d42e11a45effdd6269d605 olm.skipRange: ">=4.8.0 <4.10.0". that is the first version. I guess we needn't to set skipRange. set com.redhat.openshift.versions annotations.yaml. refer to https://docs.engineering.redhat.com/display/CFC/Delivery No "minKubeVersion": "xxxx" Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Extract the bundle image using the command below. oc image extract registry-proxy.engineering.redhat.com/rh-osbs/secondary-scheduler-operator-metadata-rhel-8@sha256:d98a19803aaa53374950bec108221729c0f9ce8e28d42e11a45effdd6269d605 Actual results: oc image extract registry-proxy.engineering.redhat.com/rh-osbs/secondary-scheduler-operator-metadata-rhel-8@sha256:d98a19803aaa53374950bec108221729c0f9ce8e28d42e11a45effdd6269d605 olm.skipRange: ">=4.8.0 <4.10.0". that is the first version. I guess we needn't to set skipRange. set com.redhat.openshift.versions annotations.yaml. refer to https://docs.engineering.redhat.com/display/CFC/Delivery No "minKubeVersion": "xxxx" Expected results: 1. No skip range should be set since this is the first release 2. com.redhat.openshift.versions should be set according to how it is being said here https://docs.engineering.redhat.com/display/CFC/Delivery 3. There is no 'minKubeVersion" set. Additional info:
``` $ oc image extract registry-proxy.engineering.redhat.com/rh-osbs/secondary-scheduler-operator-metadata-rhel-8:osso-1.0-rhel-8-containers-candidate-48922-20220224102408 W0224 11:49:34.152949 2883808 manifest.go:442] Chose linux/amd64 manifest from the manifest list. $ grep -rn "olm.skipRange" manifests/cluster-secondary-scheduler-operator.clusterserviceversion.yaml:26: # olm.skipRange: ">=4.8.0 <4.10.0" # Comment this out when a next version is released and we need to skip versions $ grep -rn "com.redhat.openshift.versions" root/buildinfo/Dockerfile-secondary-scheduler-operator-metadata-rhel-8-v1.0-1:16: com.redhat.openshift.versions="v4.10" \ $ grep -rn "minKubeVersion" manifests/cluster-secondary-scheduler-operator.clusterserviceversion.yaml:69: minKubeVersion: 1.20.10 ``` > Also i see that there is no minkubeversion set. Rama, is your expectation to have minkubeversion set or to have the field removed?
Hello Jan, My expectation is to have minkubeversion set. Thanks kasturi
Hello Jan, Few questions related to the bug here.could you please confirm the below, thanks !! 1) should not minKubeVersion be set to 1.23 as 4.10 is based on 1.23 kubernetes ? 2) i still see devpreview in the annotations, if we are planning to GA this then i think we should not have devpreview. [knarra@knarra metadata]$ cat annotations.yaml annotations: operators.operatorframework.io.bundle.channel.default.v1: "dev-preview" operators.operatorframework.io.bundle.channels.v1: "dev-preview" operators.operatorframework.io.bundle.manifests.v1: "manifests/" operators.operatorframework.io.bundle.mediatype.v1: "registry+v1" operators.operatorframework.io.bundle.metadata.v1: "metadata/" operators.operatorframework.io.bundle.package.v1: "openshift-secondary-scheduler-operator"
> should not minKubeVersion be set to 1.23 as 4.10 is based on 1.23 kubernetes ? The minKubeVersion has no effect in this case since the SSO is expected to deploy any scheduler of any version (in theory). > 2) i still see devpreview in the annotations, if we are planning to GA this then i think we should not have devpreview. I have updated the channel to stable. The changes will take effect once a next build is created.
ACK, will wait for the new build to test these changes, thanks !!
Still do not see the channel to be set to stable yet. No new build yet for the operator, will wait for the new build to test the same.
Hello Jan, I tried to verify the bug on the latest bits and i still see dev-preview being referenced. Could you please help check ? oc image extract registry-proxy.engineering.redhat.com/rh-osbs/secondary-scheduler-operator-metadata-rhel-8@sha256:90b2d91295d0e7e6af3d5e4e2e0432ad755b675f39289643af03ed953880bea9 [knarra@knarra test]$ grep -rn "channel" metadata/annotations.yaml:2: operators.operatorframework.io.bundle.channel.default.v1: "stable" metadata/annotations.yaml:3: operators.operatorframework.io.bundle.channels.v1: "stable" root/buildinfo/Dockerfile-secondary-scheduler-operator-metadata-rhel-8-v1.0-4:17: operators.operatorframework.io.bundle.channel.default.v1=dev-preview \ root/buildinfo/Dockerfile-secondary-scheduler-operator-metadata-rhel-8-v1.0-4:18: operators.operatorframework.io.bundle.channels.v1=dev-preview \ Thanks kasturi
verified in the build below and i see that skiprange is commented out, com.redhat.openshift.versions set to 4.10, minKubeVersion set to 1.20.10 and channels changed to stable. secondary-scheduler-operator-container-v1.0-11 [knarra@knarra test]$ oc image extract registry-proxy.engineering.redhat.com/rh-osbs/secondary-scheduler-operator-metadata-rhel-8@sha256:ccb6e7ef8c8b9ae178042eb9511720007c079aec63e2061e233d436a4fbc8656 W0309 18:10:22.743806 44119 helpers.go:151] Defaulting of registry auth file to "${HOME}/.docker/config.json" is deprecated. The default will be switched to podman config locations in the future version. W0309 18:10:25.067510 44119 manifest.go:442] Chose linux/amd64 manifest from the manifest list. [knarra@knarra test]$ grep -rn "olm.skipRange" manifests/cluster-secondary-scheduler-operator.clusterserviceversion.yaml:26: # olm.skipRange: ">=4.8.0 <4.10.0" # Comment this out when a next version is released and we need to skip versions [knarra@knarra test]$ grep -rn "com.redhat.openshift.versions" root/buildinfo/Dockerfile-secondary-scheduler-operator-metadata-rhel-8-v1.0-7:16: com.redhat.openshift.versions="v4.10" \ [knarra@knarra test]$ grep -rn "minKubeVersion" manifests/cluster-secondary-scheduler-operator.clusterserviceversion.yaml:69: minKubeVersion: 1.20.10 [knarra@knarra test]$ grep -rn "channel" metadata/annotations.yaml:2: operators.operatorframework.io.bundle.channel.default.v1: "stable" metadata/annotations.yaml:3: operators.operatorframework.io.bundle.channels.v1: "stable" root/buildinfo/Dockerfile-secondary-scheduler-operator-metadata-rhel-8-v1.0-7:17: operators.operatorframework.io.bundle.channel.default.v1=stable \ root/buildinfo/Dockerfile-secondary-scheduler-operator-metadata-rhel-8-v1.0-7:18: operators.operatorframework.io.bundle.channels.v1=stable \ Based on the above moving bug to verified state.
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 (Important: OpenShift Container Platform 4.11.0 bug fix and security update), 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/RHSA-2022:5069