We intentionally emit resolution errors when a ClusterCatalog is not unpacked and usable. The reason is to give cluster admins a way to reason about what resolution will give them without having to worry about the state of a particular catalog when a reconcile happens, which is not really something they can easily control.
These semantics are similar to the behavior in OLMv0, and there have been some complaints about it. For example, "I want to install CNV, I don't care if the community catalog is having issues".
In order to solve this problem, I think we need to have a knob on the ClusterExtension API to allow users to select which ClusterCatalogs to resolve from (likely using a label selector)
We intentionally emit resolution errors when a ClusterCatalog is not unpacked and usable. The reason is to give cluster admins a way to reason about what resolution will give them without having to worry about the state of a particular catalog when a reconcile happens, which is not really something they can easily control.
These semantics are similar to the behavior in OLMv0, and there have been some complaints about it. For example, "I want to install CNV, I don't care if the community catalog is having issues".
In order to solve this problem, I think we need to have a knob on the ClusterExtension API to allow users to select which ClusterCatalogs to resolve from (likely using a label selector)
_Originally posted by @joelanford in https://github.com/operator-framework/operator-controller/pull/965#discussion_r1649409460_