Epic Goal*

Document (and test) how to disable any storage integration between  OCP and vSphere in 4.12 - 4.17 clusters.

As input, there is a OCP cluster, possibly a degraded one, that fails to talk to vSphere or does not have enough permissions or whatnot.

As output, there is a perfectly working OCP cluster, only without any support for vSphere volumes. The CSI driver is not installed, vsphere-problem-detector does not report any alerts, the cluster is fully upgradeable.

The document describes steps in between, most probably using dirty tricks. We won't be able to backport a nice API to the old OCP releases.

We want to provide the document to customers on case-by-case basis. The default support should be to fix the vSphere integration, typically by providing correct vSphere credentials with correct permissions. Only the customers that don't want any vSphere integration should get the document.

Why is this important? (mandatory)

In 4.11 and older OCPs we supported clusters that had `platform: vsphere`, but  the cluster did not have any PVs and the vSphere credentials either were not valid or did not have enough permissions. As long as no vSphere PVs were used, the cluster looked healthy.

In 4.12, we insist on CSI driver installation, for which OCP needs valid credentials. Upgrade from 4.11 often renders the cluster degraded or non-upgradeable. We need to have a supported way for the customers that don't need vSphere storage and can't get proper vSphere credentials to put the cluster back to a working state and be able to upgrade the cluster to any future OCP version.

 
Scenarios (mandatory) 

As Red Hat support person, I want to give our customers a private document how to recover 4.12-4.6 cluster from errors (typically during upgrade) and how to disable any vSphere storage integrations, so my customers can bring the cluster back to a working state.

 
Dependencies (internal and external) (mandatory)

What items must be delivered by other teams/groups to enable delivery of this epic. 

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: write the doc, test it
• Documentation: review + fix the style
• QE:  test the document
• PX - notify GSS about the doc?
• Others -  notify GSS about the doc?

Acceptance Criteria (optional)

The document exists and has been tested.

Drawbacks or Risk (optional)

• It may be hard to support all failed OCP clusters - vSphere can be configured in many different ways and OCP can be broken in different ways too.
• We will need to support clusters that have `platfom: vsphere` and disabled CSI driver basically forever.

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”