Plans for v3.6.0 release

[serathius]

Based on v3.6 milestone https://github.com/etcd-io/etcd/milestone/38 release was planned for today December 15. Even though we won't be able to meet this date I think we should start the release process to make sure that we are ready for Kubernetes v1.24 release. Etcd blocks the K8s dependency upgrade including changes like #13361.

I propose to decide on major features that are still are needed for v3.6 release so we can prioritize work on them and know when to cut alpha release. Timeline proposed to make sure that we will make it for K8s v1.24 release which should be expected to happen around April 2022 (4 month release cycle):

• [Done] Agree on list major features required for v3.5
• [Done] All major features are implemented allowing us to cut v3.6.0-alpha.0.
• \Release is validated by K8s scale tests allowing us to cut v3.6.0-beta.0. [WIP] Update Etcd server image to 3.6.0-alpha.0-0 kubernetes/kubernetes#108515
• Release is continuously tested by K8s presubmits allowing us to cut v3.6.0-rc.0

This timeline reserves us 1 month for each stage that should be reserved to collecting feedback and releasing additional sub-releases.

Proposed remaining major changes for v3.6 release that need to be finished before release.

• Implement storage versioning #13168
• RFC: StoreV2 deprecation plan #12913

Remaining nice to have issues will be tracked in v3.6 milestone

Please recommend any additional changes that should be tracked.

[ahrtr]

The PR pull/13525 is fixing issue issues/13524. I added one more command-line flag "--wait-cluster-ready-timeout".

Although it's a bug fix, actually it's a small feature as well. Can we add the fix into 3.6?

[serathius]

@ahrtr Yes, it should not be a problem to add it to v3.6 . Maybe to clarify, this list is not created to limit continuous development of smaller features, but to make sure that prioritize half finished or must have features. This should allow us to make go/no go decision about starting v3.6 release process.

Not being on the list should not impact the ~100 lines of code changes like PRs that you linked. To give perspective downgrades modified more than 5000 lines of code and is maybe 70% done. We need to make sure that it is in acceptable state before releasing it to users.

I will not add this issue to this list as I looks almost done, however I think we can add it to v3.6 milestone so it will be tracked. This should allow me to ping on the issue if there would be a chance it slips.

[daviddone]

mark

[nate-double-u]

As a part of this release we'll also need to make updates to the website (currently the documentation versions are updated on the Minor releases)

[mx-psi]

I am trying to understand if the timeline at the top comment is still accurate: was the v3.6.0-alpha.0 version released yet? I can't see it in the tags on this repository.

[serathius]

We have still some PRs in flight that should be merged for alpha. They are required to make the major v3.6 features (downgrades and V2 deprecation) testable by users. Remaining PRs/issues:

• support v3 discovery to bootstrap a new etcd cluster #13635
• server: Make --v2-deprecation=write-only the default and remove not-y… #13612
• server: Switch to publishV3 #13683
• tests: Fix cluster version and downgrade request timeout #13694
• server: Snapshot after cluster version downgrade #13686
• Add downgrade commands #13687

Hope to get them ready soon.

[mx-psi]

Great, thanks for the detailed updated and for the hard work that makes this possible 🙇

[serathius]

All PRs were merged, based on that I think we are ready to cut v3.6.0-alpha.

@ptabor @spzala can you ACK if you think we can cut the release?

[ahrtr]

All PRs were merged, based on that I think we are ready to cut v3.6.0-alpha.

@ptabor @spzala can you ACK if you think we can cut the release?

Would we wait for the PR 13733? I will try to get it resolved today or tomorrow.

[serathius]

I don't think this is critical change that would block us, however we can wait if you think you can implement it soon.

[ptabor]

Release v3.6-alpha SGTM:

• I assume we don't plan to create release-3.6 branch yet and we keep main as the integration point for features for v3.6.

• I think it's critical to expand both: v3.5 and v3.6 that ensures consistency between v2state and v3state,
  i.e. if v2 store exists and it has different membership or consistency-index content vs. backend is updated to the v2 content. This requires also a decision for v3.7 behavior: whether it will move/remove storev2 files to ensure they will not get interpreted by v3.6. E.g.

  • v3.5.4+ might be reconciling the files
  • v3.6.*. might be doing startup time consistency check if both files are available. Still downgrade v3.7->v3.6 need to cover the case of v2store file being stale and getting reinterpreted.

[spzala]

v3.6-alpha SGTM too @serathius THANK you!
We should start creating doc version for 3.6 as we do have some 3.6 specific changes, I will work on it.

[serathius]

https://github.com/etcd-io/etcd/releases/tag/v3.6.0-alpha.0 is out

[serathius]

At this moment we are little late in K8s release cycle, with etcd still on alpha state, I don't think we can target K8s v1.24 release.

[serathius]

Note, further work on v3.6 release will be postponed until action items from v3.5 data inconsistency issue will be addressed.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.