cache: implement MVP watch demux

[apullo777]

This is a WIP draft PR created to start the code review process. Feedback welcome!

What’s in this PR

• implements the MVP Watch demultiplexer only, per earlier discussion with mentors
• defers the storage & indexing layer to next stage, so we can focus on correctness and robustness of the core demux

What's next

• continue writing unit tests for all demux/watch behaviors (catch-up, backoff, drop threshold, etc.)

Tagging mentors for code review:
@serathius
@MadhavJivrajani

[k8s-ci-robot]

Hi @apullo777. Thanks for your PR.

I'm waiting for a etcd-io member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[MadhavJivrajani]

Great progress! 🎉

Leaving a few comments for us to work on next week.

[ivanvc]

-release

@serathius, I had a hard time finding this message in this pull request; it has a lot of activity. I see that you suggested a change that will fix the release tests, but they are still failing. Before I investigate, is this still an issue? Please feel free to contact me on Slack.

[apullo777]

@serathius Sorry, I couldn't solve the rebase issue, and it now turns into a weird situation. I tried to do git rebase origin/main but it hit a strange issue: even with a clean working tree (both git status and git stash report no local edits), my git rebase aborts with merge conflicts with go.mod/sum files. The weird part is that Git seems to think those files are already up-to-date, so I cannot resolve the "invisible" conflict.

Stuck with this issue, I tried to force pushed a brand new branch onto the old PR branch name. That fixed the CI-side rebase error, but in doing so it also pulled in the root repo’s latest bump-Go commit (and its file changes) into my cache-mvp feature branch. So now those upstream modifications are being pushed as part of the commit, while they do not appear on my local, so I cannot remove them to update the PR commit.

At this point I can’t seem to remove them or get a clean history. Should I start over a new PR with a new branch?

[apullo777]

-release

@serathius, I had a hard time finding this message in this pull request; it has a lot of activity. I see that you suggested a change that will fix the release tests, but they are still failing. Before I investigate, is this still an issue? Please feel free to contact me on Slack.

@ivanvc Thanks for taking a look! It appears the release test is now passing, so that part is resolved. But now my feature work are polluted I will try to figure out how to solve it. Sorry for the confusion...

[serathius]

Should I start over a new PR with a new branch?

No

[serathius]

@serathius Sorry, I couldn't solve the rebase issue, and it now turns into a weird situation. I tried to do git rebase origin/main but it hit a strange issue: even with a clean working tree (both git status and git stash report no local edits), my git rebase aborts with merge conflicts with go.mod/sum files. The weird part is that Git seems to think those files are already up-to-date, so I cannot resolve the "invisible" conflict.

Yea, you broke git history. Somehow you changed the commit type to merge commit. I fixed it and pushed to your fork.
Before making any more changes please fetch the branch locally.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: apullo777, serathius

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [serathius]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[serathius]

There are still a lot of things we can improve, but this looks like a good start. The most important thing next is fixing the Atomic watch property. The current implementation assumes that revision is a unique number, this is not true.

TXN can have multiple operations (Put/Delete) that are executed within one transactions, all this operations will share revision. Atomic watch guarantee ensures that events that share revisions will always be send in single watch response and not broken up. https://etcd.io/docs/v3.5/learning/api_guarantees/#watch-apis

Prepared PR to show what I mean #20272