Story (Required)

As a cluster admin trying to use the Shared Resource CSI Driver I want the operator to deploy the Shared Resource CSI driver via an API.

<Describes high level purpose and goal for this story. Answers the questions: Who is impacted, what is it and why do we need it? How does it improve the customer’s experience?>

Background (Required)

<Describes the context or background related to this story>

After the issues deploying the driver on OCP 4.13, we have pivoted and will be deploying the Shared Resource CSI driver via the OpenShift Builds operator.

Out of scope

<Defines what is not included in this story>

• Re-productize the Shared Resource CSI driver images (see SRCD-5)
• Produce an operator that includes the re-productized CSI driver images downstream.
•  

Approach (Required)

<Description of the general technical path on how to achieve the goal of the story. Include details like json schema, class definitions>

• Add code in the operator to install Shared resources CSI driver components images (webhook, CRDs, CSI driver)
• Reconcile on any changes in the CSI drivers resources.
• Add integration tests in Konflux to verify the components are deployed.
  • Add these tests as Konflux integration test scenario, https://github.com/openshift/csi-driver-shared-resource/tree/master/test/e2e
  • Operator level smoke test around whether the objects are deployed.

Dependencies

<Describes what this story depends on. Dependent Stories and EPICs should be linked to the story.>

• BUILD-719 (Bootstrap OpenShift Builds operator)

Acceptance Criteria (Mandatory)

<Describe edge cases to consider when implementing the story and defining tests>

<Provides a required and minimum list of acceptance tests for this story. More is expected as the engineer implements this story>

• OpenShift Builds operator can deploy the Shared Resource CSI driver using upstream (non-productized) images.
• CI verifies we can deploy the Shared Resource CSI driver.
• CI verifies upgrades remain functional so we do not regress.

INVEST Checklist

• Dependencies identified
• Blockers noted and expected delivery timelines set
• Design is implementable
• Acceptance criteria agreed upon
• Story estimated

Legend

• Unknown
• Verified
• Unsatisfied

Done Checklist

• Code is completed, reviewed, documented and checked in
• Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
• Continuous Delivery pipeline(s) is able to proceed with new code included
• Customer facing documentation, API docs etc. are produced/updated, reviewed and published
• Acceptance criteria are met