Operator controller uses deppy to find solutions for existing operator CRs

[awgreene]

User Story: As a user, I would like the operator controller to be able to identify if it can install a set of bundles that satisfies the existing operator CRs.

Why is this important?

• Deppy is being developed as a framework, which will allow other projects to import Deppy as a library that can be used to identify if a set of entities can satisfy a set of constraints. The Operator Controller will then rely on the Deppy library to decide which operator must be installed on cluster based on:
  -- user constraints
  -- cluster constraints
  -- dependency constraints
  -- constraints introduced by operators currently installed
• The initial delivery tracked in this epic will only focus on supporting the following constraints:
  -- PackageName Constraints: Allowing users to specify that an entity must be from a particular package
  -- GVK Uniqueness Constraints: Allowing users to specify that GVKs introduced to the cluster must be provided by a single entity.
• Multiple operator CRs can introduce multiple PackageName constraints.

Acceptance Criteria:

• Deppy should be embedded in the Operator Controller, possibly behind an interface so it can easily be moved to its own standalone service.
• The operator controller can:
  -- identify when an operator CR cannot be satisfied.
  -- identify solutions when they exist.
• The output from Deppy will provide a list of references to bundles that were selected. These references will then be used by the operator controller to create RukPak bundleDeployments. The format of the references needs to be determined as a part of this ticket.

[oceanc80]

Assumptions:

• We will cache the catalog sources locally on the Operator Controller side
• We will use registryv1 bundles and the existing CatalogSources
• We will only allow the Operator api to communicate restraints. (Existing operators will not influence resolution).

Prereqs:

• Define global constraints: gvk and package uniqueness constraints (should be covered by OLM constraints deppy#55)
• Decide whether we want to reconcile all operator resources at once vs. one at a time Decide whether we want to reconcile all operator resources at once vs. one at a time deppy#75
• Pipe constraints into solver to get solution Pipe constraints into solver to get solution deppy#77
• Remove operator scaffolding from Deppy Remove operator scaffolding from Deppy deppy#74
• Enable Deppy to be imported by other packages Enable Deppy to be imported by other packages deppy#73

Action Items:

• Constraint generator that interfaces with the operator api (required package constraint) Convert Operator CR into Deppy Constraints #70
• Vendor Deppy framework into operator controller Vendor Deppy framework into operator controller #71
• Create an interface to Deppy that encapsulates the necessary solver methods Create an interface to Deppy that encapsulates the necessary solver methods #72
• Update Operator API resources with a status to indicate solver success/failure Update operator api resources with a status to indicate solver success/failure #73
• Deppy can take a set of constraints and return a solution set consisting of entity IDs. The Operator Controller can provide Deppy with a set of constraints and return a solution set consisting of entity IDs. #74