BUILD-256: create tech preview workflow for shared resources; employ in shared resource operator

[gabemontero]

this is the first of a series of PRs against openshift/release that will ultimately cut over all CI for https://github.com/openshift/csi-driver-shared-resource and https://github.com/openshift/csi-driver-shared-resource-operator to

• a tech preview feature gate install
• assumption that deployment of the shared resource driver operator and its operand, the shared resource driver, is handled by the inclusion of the shared resource driver operator into the list of operators managed by the cluster storage operator, where the images for the shared resource driver operator and shared resource driver deployments come from either the payload or CI's integration for updating the install payload based on PR contents.
• this change in deployments ^^ esssentially will unhook the special case deployment for these items that @adambkaplan did for us a few sprints ago, to facilitate e2e testing prior to inclusion in the CSO (as we sorted out things like name and API structure)

This initial PR takes on the following subset of that ultimate goal:

• defines the tech preview CI "workflow" we'll use (existing tech preview workflows do not meet our needs)
• switches the CI for https://github.com/openshift/csi-driver-shared-resource-operator to use that workflow

Removing the "CI induced deploy" @adambkaplan did previously, as well adjust the https://github.com/openshift/csi-driver-shared-resource CI defs and existing step registry entries if necessary, will occur in subsequent PRs.

The intent is that after this PR merges and promotes through CI, openshift/csi-driver-shared-resource-operator#10 will start passing its CI, as the running of that CI will now be on a tech preview cluster, and so @coreydaley 's recent changes to the CSO with openshift/cluster-storage-operator#224 will in fact install our operator defined at https://github.com/openshift/csi-driver-shared-resource-operator, including the declaration of our k8s CSIDriver object, and the deployment of the driver.

/assign @coreydaley

[gabemontero]

NOTE - the use of ipi-aws-pre-techpreview instead of openshift-e2e-aws-techpreview is intentional.

This meets our needs wrt running on a tech preview cluster, but does NOT pull in the default openshift/origin e2e's that are run with any openshift/origin e2e test suite.

The general CSI suite run from the cluster storage operator (they have both periodics and PR specific runs of those), will get us coverage. But our repo's PRs will be shielded from the flakes that often show up there.

[gabemontero]

ok I have to fix all the CI config check related validation jobs :-)

[gabemontero]

ah ... need to move the new workflow to a new/separate dir from the xisting e2e's

[coreydaley]

/lgtm

[gabemontero]

ok green rehearsals ... seeing if they did tech preview like we wanted

[coreydaley]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: coreydaley, gabemontero

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• ci-operator/config/openshift/csi-driver-shared-resource-operator/OWNERS [gabemontero]
• ci-operator/step-registry/csi-driver-shared-resource/e2e/OWNERS [gabemontero]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

@gabemontero: Updated the following 3 configmaps:

• ci-operator-master-configs configmap in namespace ci at cluster app.ci using the following files:
  • key openshift-csi-driver-shared-resource-operator-master.yaml using file ci-operator/config/openshift/csi-driver-shared-resource-operator/openshift-csi-driver-shared-resource-operator-master.yaml
• ci-operator-4.10-configs configmap in namespace ci at cluster app.ci using the following files:
  • key openshift-csi-driver-shared-resource-operator-release-4.10.yaml using file ci-operator/config/openshift/csi-driver-shared-resource-operator/openshift-csi-driver-shared-resource-operator-release-4.10.yaml
• step-registry configmap in namespace ci at cluster app.ci using the following files:
  • key OWNERS using file ci-operator/step-registry/csi-driver-shared-resource/e2e/techpreview/OWNERS
  • key csi-driver-shared-resource-e2e-techpreview-workflow.metadata.json using file ci-operator/step-registry/csi-driver-shared-resource/e2e/techpreview/csi-driver-shared-resource-e2e-techpreview-workflow.metadata.json
  • key csi-driver-shared-resource-e2e-techpreview-workflow.yaml using file ci-operator/step-registry/csi-driver-shared-resource/e2e/techpreview/csi-driver-shared-resource-e2e-techpreview-workflow.yaml

Details

In response to this:

this is the first of a series of PRs against openshift/release that will ultimately cut over all CI for https://github.com/openshift/csi-driver-shared-resource and https://github.com/openshift/csi-driver-shared-resource-operator to

• a tech preview feature gate install
• assumption that deployment of the shared resource driver operator and its operand, the shared resource driver, is handled by the inclusion of the shared resource driver operator into the list of operators managed by the cluster storage operator, where the images for the shared resource driver operator and shared resource driver deployments come from either the payload or CI's integration for updating the install payload based on PR contents.
• this change in deployments ^^ esssentially will unhook the special case deployment for these items that @adambkaplan did for us a few sprints ago, to facilitate e2e testing prior to inclusion in the CSO (as we sorted out things like name and API structure)

This initial PR takes on the following subset of that ultimate goal:

• defines the tech preview CI "workflow" we'll use (existing tech preview workflows do not meet our needs)
• switches the CI for https://github.com/openshift/csi-driver-shared-resource-operator to use that workflow

Removing the "CI induced deploy" @adambkaplan did previously, as well adjust the https://github.com/openshift/csi-driver-shared-resource CI defs and existing step registry entries if necessary, will occur in subsequent PRs.

The intent is that after this PR merges and promotes through CI, openshift/csi-driver-shared-resource-operator#10 will start passing its CI, as the running of that CI will now be on a tech preview cluster, and so @coreydaley 's recent changes to the CSO with openshift/cluster-storage-operator#224 will in fact install our operator defined at https://github.com/openshift/csi-driver-shared-resource-operator, including the declaration of our k8s CSIDriver object, and the deployment of the driver.

/assign @coreydaley

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.