User Story

As an OpenShift engineer
I want to run the build suite against a cluster with TechPreview feature set enabled
So that I can test using CSI volumes in builds through tech preview features

Minimum Acceptance Criteria

• CI step registry is updated so that the build suite can be run on a normal cluster as well as a cluster with tech preview enabled (e2e-build-tech-preview).
• Only one cloud provider is needed to run the build suite with tech preview enabled (aws or GCP preferred).
• The build-tech-preview test suite is added to repositories that directly impact builds:
  • openshift-controller-manager
  • cluster-openshift-controller-manager-operator
  • builder

Docs Impact

Not needed

PX Impact

None

QE Imact

None

Notes

Main entry point for adding things to the step registry: https://docs.ci.openshift.org/docs/architecture/step-registry/

To test this in CI, we need a suite that runs with the TechPreviewNoUpgrade feature set enabled. The step registry has primitives which bring up a cluster with tech preview features enabled. We will need to update ocm-o's CI configuration to run our operator tests with tech preview enabled. Testing for this specific feature will need to have separate logic that verifies we are sending the right configuration to the build controller under normal and TechPreview mode.

Existing techpreview CI step registry setups (note the per cloud elements, which make sense, since the existing CSI drivers are per cloud):

/ci-operator/step-registry/ipi/aws/pre/techpreview
./ci-operator/step-registry/ipi/azure/pre/techpreview
./ci-operator/step-registry/ipi/conf/aws/techpreview
./ci-operator/step-registry/ipi/conf/azure/techpreview
./ci-operator/step-registry/ipi/conf/techpreview
./ci-operator/step-registry/ipi/conf/openstack/techpreview
./ci-operator/step-registry/ipi/openstack/pre/techpreview
./ci-operator/step-registry/openshift/e2e/aws/techpreview
./ci-operator/step-registry/openshift/e2e/gcp/techpreview
./ci-operator/step-registry/openshift/e2e/azure/techpreview
./ci-operator/step-registry/openshift/e2e/openstack/techpreview
./ci-operator/step-registry/openshift/e2e/vsphere/techpreview

For this epic we only need to test on one cloud provider
 
Another pass:

• storage operator has e2e's for each of the close csi's , where they reference a workflow defined in the step registry: ... i.e. https://github.com/openshift/release/blob/master/ci-operator/config/openshift/cluster-storage-operator/openshift-cluster-storage-operator-master.yaml#L54-L58
• same for the indiidual csi drivers and their CSO operators .... i.e. https://github.com/openshift/release/blob/master/ci-operator/config/openshift/aws-ebs-csi-driver-operator/openshift-aws-ebs-csi-driver-operator-master.yaml#L53-L56 and https://github.com/openshift/release/blob/master/ci-operator/config/openshift/aws-ebs-csi-driver/openshift-aws-ebs-csi-driver-master.yaml#L52-L55
• in those workflows in the step registry, they have refs to the techpreview ipi chains I noted above ^^ .... i.e. https://github.com/openshift/release/blob/master/ci-operator/step-registry/openshift/e2e/aws/csi/install/openshift-e2e-aws-csi-install-workflow.yaml
• there are also these migration workflows ... perhaps related to upgrade with feature sets ... i.e. https://github.com/openshift/release/blob/master/ci-operator/step-registry/openshift/e2e/aws/csi/migration/openshift-e2e-aws-csi-migration-workflow.yaml
• there are some feature gate items in the step registry that all the csi guys seem to reference ... i.e. https://github.com/openshift/release/blob/master/ci-operator/step-registry/storage/conf/feature-gate/storage-conf-feature-gate-ref.yaml
• along with the command to do the oc path to set the feature set of the feature gate  ... i.e. https://github.com/openshift/release/blob/master/ci-operator/step-registry/storage/conf/feature-gate/storage-conf-feature-gate-commands.sh