Epic Goal*

As described in OCPBU-5, the CSO should react to the "External" platform as if it were a "None" platform. It appears that the CSO might already be doing the proper thing, but we should double check and also as noted by rhn-engineering-jsafrane in email:

I think the cluster-storage-operator already does the right thing if it finds an unknown platform. It sets Available=true, Progressing=false and it adds a new condition Disabled=true. Available condition also gets a message that there is no default storage class for this platform. See https://github.com/openshift/cluster-storage-operator/blob/220a777e094ff6b198007518d0734f9b54a7f9af/pkg/operator/defaultstorageclass/controller.go#L90
 
We may rephrase the message, because the default storage class and CSI driver could be installed by something else.

 
Why is this important? (mandatory)

In phase 2 (planned for 4.13 release) of the external platform enhancement, the new platform type will be added to the openshift/api packages. As part of staging the release of this new platform we will need to ensure that all operators react in a neutral way to the platform, as if it were a "None" platform to ensure the continued normal operation of OpenShift.

 
Scenarios (mandatory) 

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

1. As a user I would like to enable the External platform so that I can supplement OpenShift with my own CSI driver. To ensure proper operation of OpenShift, the cluster storage operator should not react to the new platform or prevent my installation of the custom driver so that I can create clusters with my own topology.

 
Dependencies (internal and external) (mandatory)

This will require OCPCLOUD-1777

Contributing Teams(and contacts) (mandatory) 

Our expectation is that teams would modify the list below to fit the epic. Some epics may not need all the default groups but what is included here should accurately reflect who will be involved in delivering the epic.

• Development -  mimccune@redhat.com , dmoiseev , Install Flex working group
• Documentation -
• QE - 
• PX - 
• Others -

Acceptance Criteria (optional)

Provide some (testable) examples of how we will know if we have achieved the epic goal. 

We are working to create an External platform test which will exercise this mechanism, see OCPCLOUD-1782 

Drawbacks or Risk (optional)

Reasons we should consider NOT doing this such as: limited audience for the feature, feature will be superseded by other work that is planned, resulting feature will introduce substantial administrative complexity or user confusion, etc.

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 -  we will perform manual test while waiting for OCPCLOUD-1782
• Documentation - only developer docs need to be updated at this time
• QE - test scenario should be covered by a cluster-wide install with the new platform type
• Technical Enablement - n/a
• Engineering Stories Merged
• All associated work items with the Epic are closed
• Epic status should be “Release Pending”