User Story

As a Red Hat engineer trying to maintain the Shared Resource CSI driver implementations for OCP and OpenShift Builds, I want to fork the current CSI Driver code into a new GitHub repository so that the "GA" code is distinct from the tech preview OCP code.

Background

As outlined in https://github.com/openshift/enhancements/pull/1457, the GA-ed version of Shared Resources CSI driver will need to live in a new GitHub repository for several reasons:

• Domain of the driver and CRD apigroups will change from sharedresources.openshift.io to sharedresources.dev. This avoids driver and API collisions if OpenShift Builds is installed on a tech preview OCP cluster (4.15 and earlier).
• Forking means the existing code can be delivered in OCP 4.15 as a deprecated feature.

Out of Scope

• Forking any code in OpenShift's storage operator.
• Removing or generalizing openshift-specific logic in the driver.
• Upstreaming to a vendor-neutral entity (ex- Kubernetes under SIG-Storage).
• Changing the domain/API groups of components.
• SDL requirements that can be met through our productization platform (CPaaS or RHTAP)
• Graduating CRD APIs to v1.

Approach (Required)

TODO - once the repository is set up, we need to make a determination on which platform will be used for CI.

Dependencies

Acceptance Criteria (Required)

• Existing Openshift-specific "tech preview" codebase can be delivered and released in OCP 4.15
• GA codebase lives on a new GitHub repository that meets Red Hat SDL requirements:
  • Least privilege permissions for write access
  • Protection for any branch used to deliver the CSI driver "downstream" (main, potential `release-n` branches for z-streams).
  • CI to verify business logic

Open Questions

• CI - continue to use openshift-cli? Notable links
  • Current config: https://github.com/openshift/release/tree/master/ci-operator/config/openshift/csi-driver-shared-resource. This will need to be copied.
  • Step-registry resources: https://github.com/openshift/release/tree/master/ci-operator/step-registry/csi-driver-shared-resource

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