*(Copied from https://issues.redhat.com/browse/OLM-2048)*

Goal: Provide immediate admin-UX improvements in the OLM APIs before the Operator API (OLM-1579) is introduced. Enable quick remediation of common error conditions in the processing installing or updating Operators by surfacing error states on the current APIs.

Background: A cluster admin installing an Operator might deal with several error conditions that are related either to the current API or related to lower-level APIs. Currently there is very little insight as in why OLM cannot fulfil a request to install or update an Operator. These range from trivial things like typos in object properties, missing RBAC to medium complexity where items cannot be loaded from the catalog because there are metadata parsing issues. Admins need to have extensive and comprehendible error reporting and messages so no understanding of the interaction process between the various lower-level API or access to the OLM pod logs is required to successfully debug.
 
Acceptance criteria:

Clear error message that don't require in-depth understand of OLM internals and cross-OLM component interaction and clear call to action, covering for example errors due to

• image pull errors
• missing related objects (OperatorGroup)
• misspelled names of referenced resources / objects
• selecting a invalid combination of a set of choices (wrong channels, Operator versions, non-existent secrets, update policies, wrongly formatted time intervals)
• OLM encountering ambiguity and requiring user input
• parsing user input data or catalog data
• mismatched dependencies
• dependency violations caused by updates
• any other condition preventing from reconciliation
• subordinate components being unhealthy
• other required components being unhealthy