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
Follow-up: we probably should not ignore unavailable catalogs. If we do, we introduce non-determinism to resolution.
If a Catalog that is needed for resolution is unavailable (that's all Catalogs right now because there's no way to disable catalogs globally or for a particular Operator), I think we should fail resolution, report the error, and then requeue when the Catalog changes state.
The text was updated successfully, but these errors were encountered:
That means that all Operator installs have a dependency on all Catalog resources being available. If someone creates a Catalog resource with an improper image (i.e not an actual catalog image) that would result in being unable to install any Operators until that is remedied which feels like a bad UX IMO. The way I am viewing it is that at resolution time we only care about resolving based on the Catalogs that are available and have been successfully unpacked. If none of them provide what we need, fail resolution. The exception here is if a user specifies that an Operator should only be installed via a specific Catalog (which I'm not sure if that is currently possible).
Mentioned in #411 (comment) by @joelanford:
The text was updated successfully, but these errors were encountered: