Off Cluster CLI Tools

[awgreene]

In the OLM Working Group and Issue Triage meeting on June 6th, 2023, @m1kola shared a demo showcasing a prototype of what an off-cluster CLI experience might look like with RukPak and Deppy. The demo generated a lot of positive feedback and the decision was made to create this GitHub Discussion with the hopes that users could document real world usecases and help define the user experience.

Refs:

• Demo: skeleton of the off-cluster OLM resolution CLI
• Demo: second iteration
• Relevant PR with usage examples

[varshaprasad96]

Adding some of the pros/cons of off-cluster resolution and management in case it helps:

Pros:

1. With this approach, we need not have to run the heavy workload of OLM v1 controllers on cluster.
2. Both the tools - resolutioncli and rukpackcli can be used declaratively to know beforehand and verify the content that will be installed on cluster. With Operator controller, the responsibility of resolving and installing the relevant bundle is completely on the hands of OLM (there are no entry points designed to intervene the process between resolution and bundle management as of now). There could be use-cases where we want to know the result of resolution, or verify the change caused by applying k8s manifests when a particular operator is mentioned for installation.

Cons:

1. We lose the benefit of lifecycle management, wherein the controllers run continuously to resolve and install/uninstall/maintain the status of operator on cluster.
2. Though the runtime inputs can be provided to the cli, these tools are more geared towards offline use-cases and cannot provide the same benefits as an on-cluster lifecycle manager would do.

[cdjohnson]

I'm not sure if all of these are directly related to THIS CLI, but some use cases I'm interested in:

High Level Question:

• I'd like to see view of what will happen to my cluster if I were to:
  1. Add/Update/Remove a CatalogSource when Operators are already provisioned.
  2. Change an Operator version/channel.
  3. Add a new Operator
  4. Remove an Operator

More specific:

1. Show the upgrade edges from an existing package+version to:
   • Current channel
   • Other potential Channels
2. Allow multiple Operator inputs (resolve as a unit)
3. Allow multiple CatalogSource inputs (using priority weighting)
4. Show the dependencies of a given package+version
   • What Packages+Channels+Versions (PCV) are required?
   • What is the state of each PCV? Provisoined, Available-NotProvisioned, Not-Available
   • What are the dependency constraints that satisfied the PCV? (GVK, Package, CEL)?
   • Which CatalogSource was used?
5. Does the collection of PVCs satisfy other cluster constraints?
   • Platform (os/architecture/variant)
   • Kubernetes version
   • Native API availability (GVK exists)
6. Will this result in a new API or Version being provisioned?
7. What (Cluster)Roles do I need to provision the new Operator(s)?
8. Is there a ConversionWebHook, Admission/MutatingWebHook included?

[m1kola]

I'm closing this discussion since we are no longer focusing (at least for now) on offline resolution. CLI tool and Deppy solver were removed from the codebase.