Hide Forgot
Description of problem: When upgrading an operator, InstallPlan execution fails if any CRD replacing an existing one has an empty versions field (but still defines the deprecated version field) Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Create an OLM catalog that contains two bundles corresponding to different CSVs that provide the same CRD, CSV-A and CSV-B, where CSV-B replaces CSV-A. The CRD should be the same in both bundles and should both specify a version field and have an empty versions field. The catalog should have a package with two channels, Channel-A and Channel-B, which have the aforementioned CSVs as their respective HEAD entries. The catalog can be image or ConfigMap sourced. 2. Create a CatalogSource in the default namespace for the catalog produced in step 1. 3. Create an OperatorGroup that supports CSV's A and B in the default namespace. 4. Create a Subscription in the default namespace for Channel-A of the package. 5. Wait for CSV-A to be installed successfully. 6. Update the Subscription to target Channel-B. Actual results: The upgrade fails and CSV-B never transitions to Succeeded. Expected results: The upgrade succeeds. Additional info: This seems to be due to some CRD upgrade validation logic not handling the deprecated version field properly (see https://github.com/operator-framework/operator-lifecycle-manager/blob/d1be59c579777d85c37f2816756c1adf4402c48f/pkg/controller/operators/catalog/operator.go#L1048:6)
Hi, Nick > The CRD should be the same in both bundles and should both specify a version field and have an empty versions field. I'm confused. As k8s documents description: "The version field is deprecated and optional, but if it is not empty, it must match the first item in the versions field." in https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/#overview So, since `specify a version field and have an empty versions field` is a wrong way, the OLM should stop it when installing the CSV-A. So, why CSV-A installed successfully? 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, 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:2922