Bug 1732914 - Operator upgrades fail when versions field of replacing CRDs is not set
Summary: Operator upgrades fail when versions field of replacing CRDs is not set
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: OLM
Version: 4.2.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.2.0
Assignee: Evan Cordell
QA Contact: Salvatore Colangelo
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-24 17:05 UTC by Nick Hale
Modified: 2019-10-27 02:31 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-16 06:31:08 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github operator-framework operator-lifecycle-manager pull 973 'None' closed Bug 1732914: Operator upgrades fail when versions field is not set 2020-10-14 05:25:46 UTC
Red Hat Product Errata RHBA-2019:2922 None None None 2019-10-16 06:31:18 UTC

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


Note You need to log in before you can comment on or make changes to this bug.