Implement compaction support in robustness test

[serathius]

No description provided.

[k8s-ci-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[serathius]

Need to fix one more case, allow gofailpoints triggered by compaction to allow to be triggered by traffic.

[serathius]

/retest

[serathius]

Yey, revision returned by compaction is not linearizable.

https://github.com/etcd-io/etcd/actions/runs/9179653925?pr=17833

cc @MadhavJivrajani @fuweid @siyuanfoundation

[siyuanfoundation]

https://github.com/etcd-io/etcd/actions/runs/9179653925?pr=17833

I don't understand why the line is drawn at the end of the compact op in the TestRobustnessExploratory_Etcd_HighTraffic_ClusterOfSize3 report.
There is a valid path from Compact(314), rev: 318 -> Compact(297), rev: 319 -> put("key0", "308"), rev: 319 -> ...
It seems Compact(297), rev: 319 should have returned ErrCompacted but didn't?

[serathius]

Assuming that compaction returns linearizable revision (that might not be necessarily a property we want to provide), operations Compact(314), rev: 318 and Compact(297), rev: 319 should not coexist. Operations execute order should follow returned revision, and it should not be possible to get both success in sequence Compact(314) and Compact(297), because it doesn't make sense to compact revision 297 after 314.

As mentioned above, it's not necessarily a bug, but at least a undocumented behavior. It stems from fact that etcd puts revision in the same field of response, independent of its meaning. Depending on the request the revision can be interpreted in a different way. Some examples:

• For PUT/TXN operations, response revision is the revision of the operation. Linearizable
• For Read request with revision=0, the response revision is the read. Linearizable
• For Read request with revision!=0, the response revision is the latest revision in cluster. Linearizable
• For Watch request, for response with events it's the revision of local member, for bookmarks it's revision of the watch stream.Non-linearizable.
• For other request I expect two cases:
  • Request goes through raft, revision is cluster revision. Linearizable. I expected Compaction is here, but it might not be.
  • Request doesn't require raft, revision is local. Non-linearizable.

[serathius]

Here is even clearer example of this