Plans for v3.5.5 release

[serathius]

Same as previous v3.5 releases. Let's agree what work should be included in release and track the work. The list presented below will be evolving as community decides to cut/include fixes.

Issues/PRs that should be included for v3.5.5:

• panic: unexpected error during txn #14110
• etcd detects data corruption by default #14039
  • Fix corruption checks v3.5 #14282
• Restriction on MaxRequestSize and maxWALEntrySize #14114
  • [3.5] Restrict the max size of each WAL entry to the remaining size of the WAL file #14127
• client/v3: do not overwrite authTokenBundle on dial #12992
  • [3.5] client/v3: do not overwrite authTokenBundle on dial #14132
• [3.5] Backport two lease related bug fixes to 3.5 #14087
• Etcd unexpected request time consumption with HTTPs v3 API #14077
  • [3.5] Support configuring MaxConcurrentStreams for http2 #14219
• Client: fix check for WithPrefix op #14182
  • [3.5] Fix Client: IsOptsWithPrefix returns false even if WithPrefix() is included #14187
• server/auth: users/authentication data not loaded on member startup #14355
  • [release-3.5] server,test: refresh cache on each NewAuthStore #14409
• ETCD has not been building artefacts for darwin/arm64 to support Apple Silicon #14001
• [release-3.5]etcdctl: allow move-leader to connect to multiple endpoints #14434

Issues/PRs not required for v3.5.5:

• Backport pull/13525 to 3.5 #14048
• Doc: provide more clarify to the usage of check perf command #14111
• AuthStore::Recover is not invalidating caches.  #13883
• Memory leak with distributed tracing enabled #13990
• Inconsistent revision and data after --force-new-cluster #14009
• ETCD Unstable under high sustained load #14072

Please feel free to suggest new additional backports/issues worth investigating so we can discuss if they should be included.
cc @ptabor @ahrtr @spzala

[ahrtr]

We may also need 14081, because there are some issues related to it. There is no update for the PR for more than 2 weeks. Just pinged the author of the PR, I will try to get it resolved if there is no update or progress this week.

[spzala]

We should include this in the v3.5.5 - #14187

[serathius]

Removed #14140 and #14143 from scope as they were reproduced on v3.4, meaning that they are not net new in v3.5. They should still be prioritized, but work can be separate from v3.5 release.

[zmt]

We are keenly interested in the open telemetry fix recently merged to the 3.5 release branch: #14312. Is there an ETA for 3.5.5 yet?

[vivekpatani]

#14355 - this should be fixed before going for 3.5.5 @serathius @spzala @ahrtr

[ahrtr]

Thanks @vivekpatani . Yes, the fix should be included in 3.5.5, and it should be a minor fix. Refer to #14355 (comment) and #14355 (comment)

The good news the bug isn't included in any published 3.5 release yet. The bad news it's already included in 3.4.20. So we need to backport the fix to 3.4 as well. Since we have simple workaround (see the links above), so it isn't a critical one.

[serathius]

With fix for #14370 merged in release-3.5 let's resume work on this.

[dims]

@ahrtr @serathius any chance of #14001 for 3.5.5?

[serathius]

Sure

[serathius]

Looks like we are ready to release v3.5.5? @ahrtr @spzala @ptabor is there important anything I missed?

[ahrtr]

Looks like we are ready to release v3.5.5? @ahrtr @spzala @ptabor is there important anything I missed?

The only concern is that we need more test this time, because there is a new feature . I suggest to run some sanity test against K8s 1.23/24.

In the meanwhile, I will try to qualify the existing functional test, so that we can also qualify 3.5.6 using the functional test next time.

[ahrtr]

I am thinking probably we should use Kubernetes's pipeline to verify etcd as well before releasing each version.

[serathius]

I worked with SIG Scalability to test v3.4.21 on 5k kubernetes cluster. Will do the same for v3.5.5. before the release.

[ahrtr]

I worked with SIG Scalability to test v3.4.21 on 5k kubernetes cluster. Will do the same for v3.5.5. before the release.

Is it possible to make this as a regular process? It isn't necessary to be the Scalability test, normal Kubernetes pipeline might be OK usually.

[serathius]

I worked with SIG Scalability to test v3.4.21 on 5k kubernetes cluster. Will do the same for v3.5.5. before the release.

Is it possible to make this as a regular process? It isn't necessary to be the Scalability test, normal Kubernetes pipeline might be OK usually.

I maintain etcd version in Kubernetes so I test all the releases. Kubernetes runs 100 node tests on all changes and 5k nodes once a week (I think). Running 5k is not a problem.

[serathius]

Release was done.