Bug 1732914

Summary: Operator upgrades fail when versions field of replacing CRDs is not set
Product: OpenShift Container Platform Reporter: Nick Hale <nhale>
Component: OLMAssignee: Evan Cordell <ecordell>
OLM sub component: OLM QA Contact: Salvatore Colangelo <scolange>
Status: CLOSED ERRATA Docs Contact:
Severity: medium    
Priority: medium CC: bandrade, chezhang, chuo, jfan, jiazha, scolange
Version: 4.2.0   
Target Milestone: ---   
Target Release: 4.2.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-10-16 06:31:08 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Nick Hale 2019-07-24 17:05:57 UTC 
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)
Comment 1 Jian Zhang 2019-08-02 11:12:08 UTC 
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!
Comment 4 errata-xmlrpc 2019-10-16 06:31:08 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:2922