Epic Goal*
We want our storage API call count + performance* not to regress between releases.

*) Performance = time to provision / attach / mount / unmount / detach / delete a volume. Not the actual bytes per second read/written to a volume.

As result, we should either have a CI job that produces numbers that we can compare across releases or a periodic chore story in each release so we do it manually.

Why is this important? (mandatory)

Some customers are especially sensitive about cloud API call count, e.g. in OCPBUGS-13125.

Scenarios (mandatory) 

As OCP developer, I want to know that we did not regress (too much) when we updated CSI sidecars and CSI driver to a new version, esp. in nr. of cloud API calls the driver and our operator does, so I can fix it early, before customers start complaining.

  
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 - 
• Documentation -
• QE - 
• PX - 
• Others -

Done - Checklist (mandatory)

• 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”