[RFE] Add storage contol plane related scenarios to ocp wrapper

[smalleni]

Is your feature request related to a problem? Please describe.

It would be good to have some scenarios that create PVCs, bind them to PVs, mount them in pods and finally reclaim them.

Describe the solution you'd like

PV/PVC related scenarios on OCP wrapper with appropriate checks that a storageclass exists in case dynamic provisioning is reqired.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

[smalleni]

Related to #426

[mfleader]

Can you define what you mean by scenario?

[afcollins]

@mfleader "scenario" just a generic term for a new workload. Like one alongside those here: https://github.com/cloud-bulldozer/kube-burner/tree/master/cmd/kube-burner/ocp-config

[mfleader]

Do the pods exist before the scenario starts?

From my initial work, it seems like you cannot mount a pvc volume by patching an existing pod.

[afcollins]

No. Think of it as you will create everything for the workload. Attaching a volume to an existing pod isn't a valid use case. Usually, you create PV/PVC first, then a pod that mounts the volume next.

Since we're interested in dynamic provisioning here, then we only need to create the PVCs and not the PVs. Maybe you'll have to create a StorageClass that supports dynamic provisioning. You'll have to do that analysis.

[mfleader]

Should this create a bunch of PVCs and Pods (like 100 each), and then reclaim the PVC and delete the Pod, or should it create 1 each and then reclaim and delete them over N iterations?

[afcollins]

Our current workloads create everything and take measurements to measure the scaleup, then delete as an unmeasured "garbage collection", but we are working towards measuring GC as well.

If you simply follow that pattern, then we can compare the added effect/overhead of PVC mounting on top of what we already understand reasonably well (e.g. node-density with added PVC).

Usually creating a single pod doesn't consume enough resources for us to measure, but we could achieve that by using churn. It could be a second phase to figure out whether churn is beneficial here and what settings to use.

[mfleader]

Should this live in cmd/kube-burner/ocp-config or in a different directory?

[afcollins]

Yes: "PV/PVC related scenarios on OCP wrapper ..."

[vishnuchalla]

Just to outline, few points to consider while adding a new workload.

• Is the workload configurable and does it follow the same pattern with other workloads when it comes to scalability standpoint?
• Are the newly added objects getting created as expected with kube-burner specific labels? Also we need to make sure if the count of created objects is verified.
• Check & verify if the measurements are being calculated as expected and they only consider the resources that are part of this newly added workload.
• Finally make sure the resources added in this new scenario are also being properly garbage collected at the end of the workload.

[mfleader]

With regards to potential dynamic storage provisioners, the obvious ones seem to be these OpenShift plugins for these platforms.

Are there other platforms that we want to test that would need a dynamic storage provisioner not already available as one of the above plugins?

[mfleader]

How do the other workloads 'scale'?

[mfleader]

How are the labels supposed to be specified?

[mfleader]

How do you verify the count of objects that have been created?

[vishnuchalla]

With regards to potential dynamic storage provisioners, the obvious ones seem to be these OpenShift plugins for these platforms.

Are there other platforms that we want to test that would need a dynamic storage provisioner not already available as one of the above plugins?

These seem to be a good enough and handful of provisioners as a part of our workload. And also I like this idea of parameterizing the STORAGE_PROVISIONER with a flexibility for user to specify it based on their requirements and infra.

[vishnuchalla]

How do the other workloads 'scale'?

https://github.com/cloud-bulldozer/kube-burner/blob/master/pkg/burner/create.go#L200

[vishnuchalla]

How are the labels supposed to be specified?

https://github.com/cloud-bulldozer/kube-burner/blob/master/pkg/burner/create.go#L207

[vishnuchalla]

How do you verify the count of objects that have been created?

https://github.com/cloud-bulldozer/kube-burner/blob/master/pkg/burner/utils.go#L82

[vishnuchalla]

Regarding mechanics and working of other workloads, I would suggest to explore the codebase and play around with it on a cluster to understand the common patterns and functionality across workloads/jobs. This is not something one could entirely help others with, requires some own research.

Docs: https://cloud-bulldozer.github.io/kube-burner/v1.7.8/

[mfleader]

I feel like we might care about the PVC claim size to cluster/node total, or free, storage size ratio, but I'm unsure how to implement that currently.

[vishnuchalla]

Yes, its good to set a smaller value as default and expose claim size as configurable option to the end user. I see current value is being set to 1GB which is too high.
cc: @afcollins