You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
LalatenduMohanty
added
v1.0
Issues related to the initial stable release of OLMv1
and removed
v1.x
Issues related to OLMv1 features that come after 1.0
labels
Oct 22, 2024
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 #965 (comment)
The text was updated successfully, but these errors were encountered: