Uploaded image for project: 'OpenShift Over the Air'
  1. OpenShift Over the Air
  2. OTA-843

Automate update-service operator artifact creation for QE

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • None
    • None
    • Automate update-service operator artifact creation for QE
    • To Do
    • None
    • 0% To Do, 0% In Progress, 100% Done
    • False
    • Hide

      None

      Show
      None
    • False
    • Not Selected
    • None
    • None
    • None

      Epic Goal*

      Several Git repositories feed the OpenShift Update Service (OSUS), which we periodically build in CPaaS and release to customers. We want to make it convenient for both devs and QE to test out current OSUS bundles without having to build anything locally, similarly to how QE uses ART-built nightly releases to investigate OCP-core.

      Why is this important? (mandatory)

      This lowers the bar for testing, and the quicker and more convenient testing is, the faster we can find bugs, and the faster we can land fixes for those bugs.

      Scenarios (mandatory) 

      QE or other interested parties should have a documented process for installing a development-tip OSUS bundle in a cluster and launching an UpdateService, without having to create things like ImageStreams and such to build them locally.

      Dependencies (internal and external) (mandatory)

      The test-platform team (DPTP) manages the Prow and ci-operator tooling we'll use to accomplish this, and we are depend on those components continuing to function. And we might discover that we need those components to be extended (e.g. perhaps they do not yet support publishing built OLM bundles or something like that).

      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 - 
      • QE - 

      The work is purely internal, so PX and doc interaction is not necessary.

      Acceptance Criteria (optional)

      A link to a doc explaining how to install OSUS and an UpdateService resource to get the current development tips that does not require local resource builds.

      Drawbacks or Risk (optional)

      Perhaps the existing QE flows are sufficiently automated that this work is unnecessary? Or perhaps QE could use some more automation, but Prow-built resources are too far from the shipped CPaaS resources for QE to want to rely on them.

      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.

      • QE - Test scenarios are written and executed successfully.

              Unassigned Unassigned
              trking W. Trevor King
              None
              None
              None
              None
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated: