OCPBU-141 - Enable sharing ConfigMaps and Secrets across namespaces [Tech Preview]
Sprint 207, Sprint 208
As an OpenShift cluster admin
I want to use the TechPreview feature set to try out CSI volumes in builds
So that I can test using CSI volumes in builds through tech preview features
Minimum Acceptance Criteria
- Openshift-controller-manager-operator reads the cluster feature gate (BuildCSIVolumes).
- If the feature gate for Build CSI volumes is enabled, the operator enables configuration in openshift-controller-manager to turn on CSI volumes for the build controller.
- CI testing verifies that we pass the appropriate feature gate to the build controller when tech preview is enabled.
Product documentation will not be required until
BUILD-275 is complete. Documentation for CSI volumes in builds will need to note that the TechPreviewNoUpgrade feature set needs to be enabled on the cluster.
Additional training enablement materials may not be needed - product docs should be sufficient.
Full e2e testing may not be feasible until
BUILD-275 is completed.
CI testing should verify that the appropriate configuration values were passed to the build controller.
We will likely need a new CI job that installs the cluster with tech preview enabled before we verify that the BuildCSIVolumes feature gate has been enabled.
- Should ocm-o mark itself Upgradeable=false if we detect the BuildCSIVolumes feature gate has been enabled?
OpenShift already has feature gates baked into the core platform via the FeatureGate API object. For this feature, we need to declare a feature gate that is added to the TechPreviewNoUpgrade feature set, which openshift-controller-manager-operator then reads and applies to the build controller.
Feature gate needs to be proposed to openshift/api (add to the TechPreviewNoUpgrade feature set).
An example PR on how to do this: https://github.com/openshift/api/pull/982.
Once approved, the updated tech preview feature set needs to be vendored into openshift/library-go.
Openshift-controller-manager-operator needs to read the feature gate, pass it on to the build controller.
The build controller has its own configuration "API" - this was a relic of the 3.x master configuration that is not exposed to admins in OCP 4.x: https://github.com/openshift/api/blob/master/openshiftcontrolplane/v1/types.go#L198-L207
A separate operator looks checks if a *NoUpgrade feature set is enabled, and if so marks the cluster as unable to be upgraded to the next minor OCP
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):
Given shared resources span all clouds, etc. does that mean we touch each of these, or create a new one, or both?
BUILD-275 Build CSI Volume Mounts
- is blocked by
BUILD-280 Feature Gates for Cluster Build Controller Config
- is related to
BUILD-275 Build CSI Volume Mounts
- split to
BUILD-349 Run Builds CI with Tech Preview Enabled
- links to