Separate Robustness compaction and LazyFS test scenario

[serathius]

Which Github Action / Prow Jobs are flaking?

https://testgrid.k8s.io/sig-etcd-robustness#ci-etcd-robustness-amd64

Which tests are flaking?

TestRobustnessExploratory/Kubernetes/LowTraffic/ClusterOfSize1/LazyFS
TestRobustnessExploratory/Etcd/LowTraffic/ClusterOfSize1/LazyFS

Github Action / Prow Job link

https://prow.k8s.io/view/gs/kubernetes-jenkins/logs/ci-etcd-robustness-amd64/1799048278302527488

Reason for failure (if possible)

Since introduction of compaction in #17833 we started getting traffic.go:129: Requiring minimal 100.000000 qps before failpoint injection for test results to be reliable, got 89.482132 qps

I would like to propose to create a separate Compaction and LazyFS as they might be too heavy to CI. For example separate TestRobustnessExploratory/Etcd/LowTraffic/ClusterOfSize1 into:

• TestRobustnessExploratory/Etcd/LowTraffic/ClusterOfSize1/Compact
• TestRobustnessExploratory/Etcd/LowTraffic/ClusterOfSize1/LazyFS

TODO:

• Add another scenario that uses traffic without compaction only when lazyfs is enabled
• Possibly reduce number of runs to avoid another scenario causing timeout due to 3h timeout.

Anything else we need to know?

No response

[serathius]

cc @MadhavJivrajani @siyuanfoundation @henrybear327 @fuweid