Uploaded image for project: 'Operator Runtime'
  1. Operator Runtime
  2. OPRUN-2151

A set of APIs for finding and installing content from indexes (Deppy)

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Obsolete
    • Icon: Critical Critical
    • None
    • None
    • None
    • A set of APIs for finding and installing content from indexes (Deppy)
    • False
    • False
    • To Do
    • OCPPLAN-7733 - Operator API
    • OCPPLAN-7733Operator API
    • 50% To Do, 0% In Progress, 50% Done
    • Undefined
    • XL

      Customer Problem: Operator Management UX

      Determining what can be installed onto a cluster based on a set of requirements and a constraints is a difficult problem to solve for OLM's on cluster boolean SAT backed resolver, never mind for end users eyeballing their constraints and determining what can be installed on a cluster. Increasingly, it is becoming difficult for an end user to be able to peel back the layers of the existing OLM APIs to determine what went wrong when an install failed. Even then, the interface and multi tenancy edges for installing bundles onto a cluster severely limits the kinds of resolution that OLM can provide today.

      Goal: Provide a first class set of lower level APIs for resolving content and constraints over a set of indexes and other cluster data to easily resolve whether a particular operator or application can be installed by OLM over time. We are tentatively calling this Deppy upstream

      Problem: OLM as is cannot easily expose arbitrary properties and constraints over a superset of the information available to it in a way that allows that information to be funneled into the existing resolver. Providing these first class APIs will allow us to build a number of core features and create user stories that will allow our higher order controllers and APIs to actually resolve some of the cluster admin and operator author requirements that are stated in https://issues.redhat.com/browse/OLM-1579

       

      Dependencies (internal and external):

       

      Prioritized deliverables (in scope / not in scope):

      1. Build a RukPak Provisioner and ProvisionerClass for resolved dependencies as resolveset bundles. (in scope)
      2. Define the Input API, which allows a user or controller to define runtime constraints (in scope)
      3. Define the InputClass API, which is a configuration of an Input that defines how to resolve a particular set of constraint types for an install (in scope)
      4. Build subscription InputClass – automatic updates for bundle and all deps (in scope)
      5. Build force InputClass – ignore other constraints and force install a bundle (in scope)
      6. Build minimal-version InputClass – install deps, but don't keep them up to date (similar to subscription API today) (in scope)
      7. Build dry-run InputClass – Don't install, just provide resolution result (in scope)

       

      Estimate (XS, S, M, L, XL, XXL): XL

              jlanford@redhat.com Joe Lanford
              krizza@redhat.com Kevin Rizza
              Votes:
              7 Vote for this issue
              Watchers:
              34 Start watching this issue

                Created:
                Updated:
                Resolved: