Enable churn for our node-density tests

[jtaleric]

Type of change

• Refactor
• New feature
• Bug fix
• Optimization
• Documentation Update

Description

Enabling churn (default :false) for our node-density tests in kube-burner-ocp

Related Tickets & Documents

• Related Issue #
• Closes #

Checklist before requesting a review

• I have performed a self-review of my code.
• If it is a core feature, I have added thorough tests.

[jtaleric]

@rsevilla87 / @vishnuchalla any feedback?

[rsevilla87]

@jtaleric , when using churnDeletionStrategy: default, kube-burner will remove the node-density namespace, maybe we can can consider using gvr to have a better control on how the workload behaves?

[rsevilla87]

Also, another thing to keep in mind is that workload usually creates just one namespace, (in standard node-density at least), and churnPercent is calculated from the number of created namespaces for standard node-density the churning stage will just remove that namespace, is that what we're pursuing with this change?

[jtaleric]

Let me know if these changes address your concerns @vishnuchalla / @rsevilla87 . Thanks!

[afcollins]

I believe the concern is in the churn logic in kube-burner uses namespaces as unit to delete.

We could achieve the same effect using iterationsPerNamespace=1 when we use churn on the cni and heavy workloads to get the desired effect. Since using churn with these workloads changes the workload as we understand them, changing itsPerNs may be fine for this purpose.

I think we could add these flags at this time to make them available in kube-burner-ocp.
I created kube-burner/kube-burner#673 to track that refactoring.

[jtaleric]

I believe the concern is in the churn logic in kube-burner uses namespaces as unit to delete.

We could achieve the same effect using iterationsPerNamespace=1 when we use churn on the cni and heavy workloads to get the desired effect. Since using churn with these workloads changes the workload as we understand them, changing itsPerNs may be fine for this purpose.

I think we could add these flags at this time to make them available in kube-burner-ocp. I created kube-burner/kube-burner#673 to track that refactoring.

@afcollins I was under the impression moving to gvr vs default for churn strategy would help with this?

churnDeletionStrategy	Churn deletion strategy to apply, default or gvr (where default churns namespaces and gvr churns objects within namespaces)	String	default

@rsevilla87 / @vishnuchalla can someone confirm the difference between gvr and default ?

[afcollins]

Oh! I see now that yes, it looks like gvr deletion strategy does not blindly delete the entire namespace at once. But I don't see that it is tracking the resources that make up an iteration. It is still only deleting a namespace as a unit, but just in a different way.

[vishnuchalla]

I believe the concern is in the churn logic in kube-burner uses namespaces as unit to delete.
We could achieve the same effect using iterationsPerNamespace=1 when we use churn on the cni and heavy workloads to get the desired effect. Since using churn with these workloads changes the workload as we understand them, changing itsPerNs may be fine for this purpose.
I think we could add these flags at this time to make them available in kube-burner-ocp. I created kube-burner/kube-burner#673 to track that refactoring.

@afcollins I was under the impression moving to gvr vs default for churn strategy would help with this?

churnDeletionStrategy	Churn deletion strategy to apply, default or gvr (where default churns namespaces and gvr churns objects within namespaces)	String	default

@rsevilla87 / @vishnuchalla can someone confirm the difference between gvr and default ?

@jtaleric gvr deletes all the individual resources in a namespace with configured QPS and Burst instead of directly deleting a namespace which will be similar to oc delete ns namespace (.i.e. default strategy). So it still deletes the entire namespace in a less intensive way.

Regarding iterations, yes with the latest commit in this PR we can achieve that behavior by considering each namespace as an iteration (i.e. similar to other workloads). Hopefully that solves your purpose. If not, and if you strongly wish to have all the iterations within a singe namespace then we might have to think something like kube-burner/kube-burner#673. But before that I would like to understand why do we want all the iterations in a single namespace?

[jtaleric]

I believe the concern is in the churn logic in kube-burner uses namespaces as unit to delete.
We could achieve the same effect using iterationsPerNamespace=1 when we use churn on the cni and heavy workloads to get the desired effect. Since using churn with these workloads changes the workload as we understand them, changing itsPerNs may be fine for this purpose.
I think we could add these flags at this time to make them available in kube-burner-ocp. I created kube-burner/kube-burner#673 to track that refactoring.

@afcollins I was under the impression moving to gvr vs default for churn strategy would help with this?

churnDeletionStrategy	Churn deletion strategy to apply, default or gvr (where default churns namespaces and gvr churns objects within namespaces)	String	default

@rsevilla87 / @vishnuchalla can someone confirm the difference between gvr and default ?

@jtaleric gvr deletes all the individual resources in a namespace with configured QPS and Burst instead of directly deleting a namespace which will be similar to oc delete ns namespace (.i.e. default strategy). So it still deletes the entire namespace in a less intensive way.

Regarding iterations, yes with the latest commit in this PR we can achieve that behavior by considering each namespace as an iteration (i.e. similar to other workloads). Hopefully that solves your purpose. If not, and if you strongly wish to have all the iterations within a singe namespace then we might have to think something like kube-burner/kube-burner#673. But before that I would like to understand why do we want all the iterations in a single namespace?

For my vary narrow focused work, having 1 iteration == 1 namespace does suffice.

[github-actions]

This pull request has become stale and will be closed automatically within 7 days.

[memodi]

@jtaleric thanks for this PR, I think this would be will very helpful to exercise some of the network observability components like flowlogs-pipeline