Bug 1732579

Summary: CatalogSources should be permissive to errors in manifests
Product: OpenShift Container Platform Reporter: Evan Cordell <ecordell>
Component: OLMAssignee: Evan Cordell <ecordell>
OLM sub component: OLM QA Contact: Fan Jia <jfan>
Status: CLOSED ERRATA Docs Contact:
Severity: medium    
Priority: medium CC: bandrade, chuo, jfan, jiazha, nhale
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:30:48 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:
Bug Depends On:    
Bug Blocks: 1732580    

Description Evan Cordell 2019-07-23 19:17:17 UTC
Description of problem:

Operator-Registry is a component of OLM that serves operator metadata for a cluster. These servers get built at runtime by the marketplace-operator, which reads from a remote appregistry store and parses them for local use. Any number of issues can arise with the parsing of these manifests which causes the pod serving this data to fail with an error message.

Instead of failing, operator-registry should be permissive in the parsing of manifests, so that an entire catalog isn't out of commission if there are errors in the source data.


How reproducible:

Always


Steps to Reproduce:

(as an example)
1. Push manifests to an appregistry repo (like community-operators) that has a ClusterServiceVersion with a "replaces" field set to "thisWillFail"
2. Create an OperatorSource pointing to this appregistry repo
3. Note the failing pod in the cluster.

Actual results:

The CatalogSource pod never becomes healthy.


Expected results:

The CatalogSource loads, with bad manifests removed.

Comment 3 errata-xmlrpc 2019-10-16 06:30:48 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