Uploaded image for project: 'Cluster Integration and Delivery'
  1. Cluster Integration and Delivery
  2. CLID-92

Publish versions of operators which are mirrored

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • oc / oc-mirror
    • None
    • False
    • Hide

      None

      Show
      None
    • False
    • 0

      Epic Goal*

      As a user mirroring operators, I want to be able to tell what versions of each operator has been mirrored

       
      Why is this important? (mandatory)

      Currently when operators are mirrored there is no way for a user to tell what version of the operator was mirrored from the tool itself. Without putting the previously mirrored version into the imageset config, simply running oc mirror again will mirror the latest version with no guarantee there is a path to upgrade.

      Even if the tool can understand 

       
      Scenarios (mandatory) 

      1. User mirrors the ansible automation platform operator today
      2. in 2 weeks the user wants to mirror the latest version using the initial version as the minVersion (starting point)
      3. There is no way for the user to know this information.

       
      Dependencies (internal and external) (mandatory)

      none

      Contributing Teams(and contacts) (mandatory) 

      Our expectation is that teams would modify the list below to fit the epic. Some epics may not need all the default groups but what is included here should accurately reflect who will be involved in delivering the epic.

      • Development - 
      • Documentation -
      • QE - 
      • PX - 
      • Others -

      Acceptance Criteria (optional)

      When an operator is mirrored, the output includes the version of the operator that was mirrored 

      Drawbacks or Risk (optional)

       

      Done - Checklist (mandatory)

      The following points apply to all epics and are what the OpenShift team believes are the minimum set of criteria that epics should meet for us to consider them potentially shippable. We request that epic owners modify this list to reflect the work to be completed in order to produce something that is potentially shippable.

      • CI Testing -  Basic e2e automationTests are merged and completing successfully
      • Documentation - Content development is complete.
      • QE - Test scenarios are written and executed successfully.
      • Technical Enablement - Slides are complete (if requested by PLM)
      • Engineering Stories Merged
      • All associated work items with the Epic are closed
      • Epic status should be “Release Pending” 

            Unassigned Unassigned
            dan5179 Dan Clark
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: