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

Lower resource consumption of global operators (Copied CSV Toggle)

XMLWordPrintable

    • Avoid CSV copying
    • False
    • False
    • Done
    • OCPPLAN-7751 - Descoping Preparation
    • OCPPLAN-7751Descoping Preparation
    • 0% To Do, 0% In Progress, 100% Done
    • Undefined
    • L
    • 0

      Epic Goal

      • Non-admin users can understand what services are available for them to use
      • Authors and admins have fine-grained control over which users can see what services
      • The implementation to make operators discoverable by users must scale well / remove the need to copy data around in the clusters into every namespace

      Why is this important?

      • CSV copying is a constant source of performance and scale problems for OLM and needs to be removed
      • Cluster visibility is a common reason given to why operator authors avoid "AllNamespace" operators - they don't want the CSV to pop up in every namespace. AllNamespace operators are the simplest to treat as "descoped", so if we can solve the visibility problem today, we can avoid migration pain in the future.

       

      For 4.10, this Epic is delivering a toggle to disable copied CSVs for operators in the all namespace mode.  This is intended for large clusters with a large number of all namespace operators and namespaces.  This will provide relief for clusters that experience large CPU or memory usage.  

       

      With the copied csv toggle on to prevent copied csvs, there will be impacts to console.  We will provide explicit information about what is not available in the documentation and make sure that cluster admins are aware of the impacts of that switch. 

      Please see https://github.com/operator-framework/enhancements/blob/master/enhancements/olm-toggle-copied-csvs.md#risks-and-mitigations

      for more information.

       

      We need to have follow on conversations with PM and the console team about potential follow on work to deal with impacts in the console.

      Related work

      Scenarios

      1. As a non-admin user, I would like to tell what services (operators and their apis) I am permitted to use.
      2. As an operator author, I would like to control the default visibility of the operator and its services.
      3. As an admin, I would like to adjust the visibility of an operator and its services after installation.
      4. As a admin, I want to enable global operators on clusters with a lot of namespaces without massive resource overhead in the OLM controllers

      Acceptance Criteria

      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.
      • Scale testing - the new mechanism must scale better than manifest size * namespaces

      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>

            njhale Nicholas Hale (Inactive)
            rhn-coreos-ecordell Evan Cordell (Inactive)
            Jian Zhang Jian Zhang
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: