---
# System prepended metadata

title: Proxying PO Status Back to CVO

---

# Proxying PO Status Back to CVO

## Summary

See https://issues.redhat.com/browse/OLM-2688 for JIRA ticket. 

For phase 0, the PO manager component will be responsible for acting as a proxy to the CVO for communicating the overall state of individual PO packages. This can be done by managing an "aggregate" ClusterOperator resource, which can be used to communicate the status of POs during phase 0. During failed installations of individual POs, the expectation is that the cluster rollout will fail like it would for CVO-based components today.

Note: blocking cluster updates based on PO status is not in-scope for phase 0. This is solely focused on ensuring POs rollout successfully on cluster creation, or else fail the installation. 

## Implementation 

The PO manager will need to reconcile an "aggregate" ClusterOperator resource in order to communicate PO state back to the CVO. This can be managed by a separate controller as part of the POM payload. This controller would only need to parse the PO's status conditions and check whether the PO is in an error state. This could occur if a.) the Bundle failed to unpack, or b.) whether the underlying BundleDeployment cannot be successfully applied to the cluster. 

This separate controller would be responsible for reconciling a singleton ClusterOperator resource, and watches for new events for the PO resource. In the main reconciliation logic it lists all the PO resources on the cluster, parses their statuses, and aggregates that state back to the CO object it's reconciling.

### Scenarios
* An individual PO that specifies a non-existent OLM package name would result in a failed cluster installation.
* An individual PO that fails to unpack the sourced bundle contents would result in a failed cluster installation.
* An individual PO managing a BD that fails to pass API server validation results in a failed cluster installation.
* * An individual PO managing a BD that fails to rollout successfully results in a failed cluster installation. 
* All individual POs successfully installed would result in a successful cluster installation state from the perspective of PO.

### Controller Logic
A singleton CO object representing the state of all POs will be deployed by CVO alongside the POM. The controller can assume this object exists (potentially called "platform-operators") and do nothing if it is not found.

1. Get the singleton CO object from the cache
2. Do a list over all POs on the cluster from the cache
3. Iterate over all POs, inspecting the status for signs of failure. 
4. If any PO is in a failed state, update the singleton CO object to a failed state with a detailed explanation of which PO is failing and why.
5. If all POs are in a healthy state, update the singleton CO to be in a healthy state (or do nothing)

The controller should avoid modifying the singleton CO if nothing has changed.

## Open questions
* How to handle a PO flapping when writing to the singleton CO? For example, an installation may fail in a transient nature (for example, an external registry cannot be reached intermittently to pull down the bundle image). Since the CO status is continually reconciled, the controller would put the status as failing for that particular PO, and then would update it on the next reconciliation loop if the issue went away. This has implications for how CVO manages its own status. 

Answer: The aggregate CO should be in "progressing=true/available=false" until all the POs reach a terminal "successful install" state.