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

OLM allows auto-approval so tenants can install Operators

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • Tenants can install Operators
    • False
    • False
    • To Do
    • OCPSTRAT-376 - OLM 1.0 - Request / Approval Flow for Installs / Updates (F11)
    • OCPSTRAT-376OLM 1.0 - Request / Approval Flow for Installs / Updates (F11)
    • 0
    • 0% 0%
    • Undefined
    • 0

      Epic Goal

      • Allow administrator to configure self-service Operator installs for any tenants on a per catalog level

      Why is this important?

      • Cluster-admin involvement/approval is frequently reported as a barrier to Operator adoption
      • In certain use cases it is perceived as an acceptable risk to let cluster tenants install Operators
      • The current implementation requires admins hand picking namespaces and RBAC scope upfront which is tedious and also forces a namespaced installs which we want to move away from

      Scenarios

      1. A development cluster is provisioned for experimental use and this experimentation should allow for exploratory use of Operators
      2. An admins configures OLM to auto-approve any Operator install attempt for Operators from a certain catalog
      3. A tenant can see the Operator catalog and request an install, this request would cause an approval flow similar to how Certificate Signing Requests are used in Kubernetes - normally this is where the admin would intervene to deny the install or approve it to move forward
      4. If the Operator comes from a catalog that is configured for auto-approval OLM would automatically approve the install request on behalf of the cluster admin and the install would proceed as if it was triggered / approved by a human admin
      5. Cluster users should also be able to request access to an already installed Operator, in which case the deployment would be skipped and the existing access scope of the Operator and tenant widened to include the tenant
      6. Auto-installed Operator should still allow to adjust the visibility and accessibility by the user but only to namespace where they have namespace admin permissions

      Acceptance Criteria

      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.
      • Upstream documentation
      • Downstream documentation

      Dependencies (internal and external)

      1. Approval mechanism that gates Operator install OLM-1786

      Previous Work (Optional):

      1. ServiceAccount support in OperatorGroups (install delegation)

      Open questions::

      Done Checklist

      • CI - CI is running, tests are automated and merged.
      • Release Enablement <link to Feature Enablement Presentation>
      • DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
      • DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
      • DEV - Downstream build attached to advisory: <link to errata>
      • QE - Test plans in Polarion: <link or reference to Polarion>
      • QE - Automated tests merged: <link or reference to automated tests>
      • DOC - Downstream documentation merged: <link to meaningful PR>

       
       
       

       

            Unassigned Unassigned
            DanielMesser Daniel Messer
            Votes:
            1 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: