Epic Goal*

In order to implement Volume Populators in OCP properly, we need to ship & install volume-data-source-validator as part of OCP.

Why is this important? (mandatory)

volume-data-source-validator is an external controller that "will emit an event on the PVC informing the user that the PVC is currently not being acted on, so the user can fix any errors, and so the user doesn't wait forever wondering why the PVC is not binding". Typically when users provides a PVC with invalid pvc.spec.dataSourceRef.

It is a cluster-wide controller that should be shipped by a Kubernetes vendor and it will validate all PVCs that use volume populators provided by third parties.

Note that users will get only better UX, volume populators will work without volume-data-source-validator.

It is nice to have when having volume populators as tech preview, we should ship it when they get GA.

See upstream KEP for details.

Scenarios (mandatory) 

Provide details for user scenarios including actions to be performed, platform specifications, and user personas.  

1. As a cluster admin, I get the volume-data-source-validator + VolumePopulator CRD installed by default in an OCP cluster, so I don't need to worry about it.
2. As an user, I get an event when I use unknown volume populator in my pvc.spec.dataSourceRef.

Open Questions

1. Do we need a separate operator or can we put it into cluster-storage-operator? This means the volume-data-source-validator will be part of "Storage" capability.
2. Shall we make it optional / opt-in via OLM? We don't ship any volume populators in OCP (yet). OLM should allow dependencies between operators, so when a populator operator is installed, it could install also volume-data-source-validator-operator.

 
Dependencies (internal and external) (mandatory)

Has to be done in order:

1) Fork upstream repository (STOR-2412)
2) Onboard with CI/DPTP (STOR-2452)
3) Request new image build with ART (STOR-2487)

Contributing Teams(and contacts) (mandatory) 

• Development 
• Documentation
• QE
• PX 

Acceptance Criteria (optional)

Drawbacks or Risk (optional)

This could be an optional component delivered via OLM.

Done - Checklist (mandatory)

The following points apply to all epics and are what the OpenShift team believes are the minimum set of criteria that epics should meet for us to consider them potentially shippable. We request that epic owners modify this list to reflect the work to be completed in order to produce something that is potentially shippable.

• CI Testing -  Basic e2e automationTests are merged and completing successfully
• Documentation - Content development is complete.
• QE - Test scenarios are written and executed successfully.
• Technical Enablement - Slides are complete (if requested by PLM)
• Engineering Stories Merged
• All associated work items with the Epic are closed
• Epic status should be “Release Pending”