Uploaded image for project: 'Operator Ecosystem'
  1. Operator Ecosystem
  2. OPECO-2591

[Pilot phase] Community operator authors have a clean approach to supporting FBC for multiple OCP releases

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Done
    • Icon: Major Major
    • openshift-4.14
    • openshift-4.14
    • None
    • FBC: 1TO5
    • False
    • None
    • False
    • Not Selected
    • Done
    • OCPSTRAT-586 - [Pilot phase] Enable managing releases with the file-based catalog for Red Hat Operator teams with RHTAP
    • OCPSTRAT-586[Pilot phase] Enable managing releases with the file-based catalog for Red Hat Operator teams with RHTAP
    • 100
    • 0% To Do, 0% In Progress, 100% Done

      OCP/Telco Definition of Done
      Epic Template descriptions and documentation.{}

      Epic Goal

      • OCP community operator authors need a clean approach to support multiple OCP releases with minimal veneer/FBC.  As part of https://docs.google.com/document/d/1DZaDkZz8l-L911tZ26_5lmm8uYJ8g9etBWRXbUeSLdM/edit#heading=h.h9wqoxeg6yjv Model A we must support the current ecosystem, which includes a common location for operator bundles.  We must overlay FBC-generation capabilities as part of the existing repository organization to provide authors with control over their catalog contributions without necessitating re-homing their bundles, catalog contributions to discrete repositories.
      • This epic captures the pieces of this work necessary for the pilot phase.

      Why is this important?

      • Operator authors have expressed reluctance to migrate to FBC given that they
        • now have to separately manage their upgrade graph catalog contribution; and
        • may have to separately manage per-supported-OCP-version veneer/FBC information; and
        • may not be able to leverage veneers while retaining control of which bundles are included for each release

      Scenarios

      1. author needs to use different veneer types for different OCP releases
      2. author needs to generate FBC for multiple releases from the same template
      3. author needs to omit some bundle versions from some subset of supported OCP releases
      4. author needs to automate a toolchain containing these steps (i.e. cannot force interactive mode)

      Acceptance Criteria

      • CI - MUST be running successfully with tests automated
      • output must be idempotent given same inputs
      •  

      Dependencies (internal and external)

      1. multiple-release support: work with lgallett and team to collaborate on https://docs.google.com/document/d/1uEZdVA06GGahPl3ygnGrFLRkrohaQjs25mVcXToYakE
      2.  

      Previous Work (Optional):

      1. Rejected proposal for `veneergroup` veneer https://hackmd.io/dD3h4K3tRi-fF3Z3SAuGKA
      2. Demonstrated veneergroup-via-Makefile approach: https://github.com/ankitathomas/veneergroup
      3. "Covington" veneer proposal, containing bundle optionality: https://hackmd.io/q8uAu2PjRZSlueutc5McBw#Covington
      4.  

      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>

       

       

            rh-ee-jkeister Jordan Keister
            rh-ee-jkeister Jordan Keister
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: