Stop generating v2 snapshot files, nor loading v2 snapshot files

[ahrtr]

Link to #20187

This PR stops generating v2 snapshot files, nor loading it at all.

[ahrtr]

cc @fuweid @serathius

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 69.71%. Comparing base (ee043b3) to head (5d1a827).

Additional details and impacted files

Files with missing lines	Coverage Δ
server/etcdserver/cluster_util.go	66.17% <ø> (-0.14%)	⬇️
server/etcdserver/server.go	83.99% <100.00%> (+0.21%)	⬆️
server/etcdserver/snapshot_merge.go	76.47% <ø> (-1.31%)	⬇️
server/storage/storage.go	60.46% <ø> (+1.76%)	⬆️

... and 23 files with indirect coverage changes

@@           Coverage Diff           @@
##             main   #22263   +/-   ##
=======================================
  Coverage   69.70%   69.71%           
=======================================
  Files         449      449           
  Lines       38212    38187   -25     
=======================================
- Hits        26635    26621   -14     
- Misses      10142    10147    +5     
+ Partials     1435     1419   -16     

---

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ee043b3...5d1a827. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ahrtr]

/test pull-etcd-e2e-amd64

[serathius]

What kind of tests we have to ensure downgrade works? IIRC v3.8 will not generate snapshots, v3.7 generates but not need them, but v3.6 will still need them.

Do we care about users going down from v3.8 to v3.6 via etcdutl? Do we have any safeguards around this?

[ahrtr]

We should be good as long as the existing e2e test cases (including downgrade test cases) are green.

We only support two major/minor releases, when v3.8 is out, v3.6 should be almost end of support. In practice, we don't expect users downgrade from v3.8 to v3.6. Also In K8s use cases, in most cases, even users upgrade or downgrade (AFAIK, K8s doesn't even support downgrade) multiple K8s versions, etcd is the same minor version.

• K8s 1.34 - 1.36 depends on etcd v3.6
• K8s 1.37 - (at least K8s 1.39+) depends on etcd v3.7
• At least K8s 1.40+ depends on etcd v3.8.

For the etcdutl case, we can document that it only support v3.8 and v3.7, or document that we only support upgrade or downgrade one version at a time. If users want to continue to downgrade (not recommended, or not even supported if v3.6 if EOL) when they are already on v3.7, then they should use the the same version of etcdutl (v3.7)

IIRC v3.8 will not generate snapshots

FYI. This is exactly what this PR is doing.

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ahrtr, fuweid, 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 [ahrtr,fuweid,serathius]

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

[ahrtr]

thx for the quick review!

[ahrtr]

For the etcdutl case, we can document that it only support v3.8 and v3.7, or document that we only support upgrade or downgrade one version at a time. If users want to continue to downgrade (not recommended, or not even supported if v3.6 if EOL) when they are already on v3.7, then they should use the the same version of etcdutl (v3.7)

It turns out that this PR has no impact on etcdutl restore command at all (manually tested: start etcd v3.5.30 from the data restored from etcdutl v3.8), because etcdutl restore always reset both the consistent_index and commit index, see #12369 (comment)