When a CSV has invalid yaml (missing "apiVersion:" line in my case), I was able to build bundle + index image with it and installation of the operator in a cluster failed with cryptic "error creating service account" in InstallPlan status. Version-Release number of selected component (if applicable): Server Version: 4.9.0-0.nightly-2021-07-15-015134 How reproducible: Always Steps to Reproduce: 1. Use a CSV without "apiVersion:" line. 2. Build bundle image + index image. I don't use operator-sdk tooling for that, I use plain: docker build -f ./bundle.Dockerfile -t quay.io/jsafrane/efs:bundle . docker push quay.io/jsafrane/efs:bundle opm index add --bundles quay.io/jsafrane/efs:bundle --tag quay.io/jsafrane/efs:index --container-tool docker docker push quay.io/jsafrane/efs:index 3. Install the operator in an OCP cluster Actual results: InstallPlan shows weird message in its status: conditions: message: 'error creating service account: aws-efs-csi-driver-operator: ServiceAccount "aws-efs-csi-driver-operator" is invalid: metadata.ownerReferences.apiVersion: Invalid value: "": version must not be empty' reason: InstallComponentFailed status: "False" type: Installed Expected results: - "opm index add" fails nicely - InstallPlan status shows "failed to parse CSV: <some nice message>". Even message shown by "oc apply invalid-csv.yaml" is better than complaining about service account: > no matches for kind "ClusterServiceVersion" in version ""
Bug fix is being pulled down here: https://github.com/openshift/operator-framework-olm/pull/305
Scratch that. I've created a bug PR: https://github.com/openshift/operator-framework-olm/pull/307
@jsafrane Hi, per ticket description "When a CSV has invalid yaml (missing "apiVersion:" line in my case), I was able to build...", it seems the bad csv should be --- { "kind": "ClusterServiceVersion", "metadata": { "annotations": { "alm-examples": "[]", "capabilities": "Full Lifecycle", "categories": "Storage", "certified": "false", "containerImage": "quay.io/app-sre/aws-efs-operator:latest", "createdAt": "2020-04-18T21:43:33Z", "description": "Management of AWS EFS read-write-many mounts.", "operators.operatorframework.io/builder": "operator-sdk-v1.4.0+git", "operators.operatorframework.io/project_layout": "unknown", "repository": "https://github.com/openshift/local-storage-operator", "support": "Red Hat" }, "name": "aws-efs-operator.v4.8.0", "namespace": "openshift-operators" }, ... --- which has no ' "apiVersion": "operators.coreos.com/v1alpha1",' but after I unpack quay.io/jsafrane/efs:bundle, I find bad csv has apiVersion, but has no items (like apiVersion) in metadata.annotation.alm-examples which is --- { "apiVersion": "operators.coreos.com/v1alpha1", "kind": "ClusterServiceVersion", "metadata": { "annotations": { "alm-examples": "[]", "capabilities": "Full Lifecycle", "categories": "Storage", "certified": "false", "containerImage": "quay.io/app-sre/aws-efs-operator:latest", "createdAt": "2020-04-18T21:43:33Z", "description": "Management of AWS EFS read-write-many mounts.", "operators.operatorframework.io/builder": "operator-sdk-v1.4.0+git", "operators.operatorframework.io/project_layout": "unknown", "repository": "https://github.com/openshift/local-storage-operator", "support": "Red Hat" }, "name": "aws-efs-operator.v4.8.0", "namespace": "openshift-operators" }, --- So, I want to double confirm with you what your bad csv means. no `"apiVersion": "operators.coreos.com/v1alpha1"` or has `"apiVersion": "operators.coreos.com/v1alpha1"`, but no anything in alm-examples? Thanks
@jsafrane could you please check the comment https://bugzilla.redhat.com/show_bug.cgi?id=1982737#c5? thanks
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
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days