Documentation: add roadmap #16279
Documentation: add roadmap #16279
Conversation
|
cc @mitake @ptabor @serathius @spzala @wenjiaswe @etcd-io/members @logicalhan cc @tbg @pavelkalinnikov @erikgrinaker FYI. I am planning to release raft 3.6.0 sometime this year. |
I'm a little bit worried about releasing 3.6 without having the full downgrade story worked out for 3.4->3.5 first. |
| ## v3.6.0 | ||
| | Title | Priority | Note | | ||
| |--------------------------------------------------------------------|----------|--------------------------------------------------------------------------------------------------------------| | ||
| | Support downgrade | P0 | etcd will support downgrade starting from 3.6.0. But it will also support offline downgrade from 3.5 to 3.4. | |
There was a problem hiding this comment.
I would like online downgrade from 3.5 -> 3.4 to be backported.
There was a problem hiding this comment.
That's too much work and too risky. You would need to backport everything listed in #13168.
There was a problem hiding this comment.
It's also risky to upgrade to 3.5 without a fallback plan.
There was a problem hiding this comment.
Offline downgrade is the fallback.
ahrtr
force-pushed
the
roadmap_20230721
branch
2 times, most recently
from
467f49c
to
b56c0f3
Compare
Agree, several cloud providers are still on etcd 3.4, releasing 3.6 means 3.4 will not be supported any more, but upgrading from 3.4 to 3.5 is too risky without having a downgrade support. |
thx for the feedback. Please see the discussion in #15878, and feel free to add comment in that ticket. |
|
I revisited the existing pull requests. Since the compacted resource version might cause list-all request in Kubernetes, it's easy to cause OOM-Killed. IMO, we should consider to continue the work of #12343 and introduce max_bytes limit in one response #14810 in 3.6 or 3.7. CC @linxiulei |
| |-----------------------------------------------------------|----------|------| | ||
| | Remove the dependency on grpc-go's experimental API | | | | ||
| | Protobuf: cleanup both golang/protobuf and gogo/protobuf | | | | ||
| | Proposals should include a merkle root | | | |
There was a problem hiding this comment.
Merkele root for me is a P1 for v3.6.0 as proposed in https://github.com/etcd-io/etcd/blob/main/Documentation/postmortems/v3.5-data-inconsistency.md#action-items
I want to pick this up after robustness tests.
There was a problem hiding this comment.
I do not see a clear or feasible solution so far. We can have more discussion in future.
There was a problem hiding this comment.
I have couple of ideas, just need to write down the design.
I do not have enough confidence to pick it up in 3.6 timeframe for now. But it's open for discussion, and we can evaluate it separately. |
That's why it's not a P0, but a P1. We can start planning it in v3.6.0, but have a full feature available in v3.7.0 |
Signed-off-by: Benjamin Wang <wachao@vmware.com>
|
Good point. Just changed the priorities to P0 for the two items you mentioned. Thanks @spzala |
|
With the approval from 3 maintainers and 3 members/contributors, merging this PR... Just as discussed above, it isn't set in stone, it may shift over time. [But I don't expect too much change for 3.6]. The roadmap just gives a high level direction of the project for the next few major or minor releases. It doesn't mean we will never receive any features which are not included in the list. |
Add a roadmap so that all contributors and users know the priorities of each major or minor release. Note that etcd community will continue to focus on technical debt over the next few major or minor releases.
Please read https://github.com/etcd-io/etcd/blob/main/CONTRIBUTING.md#contribution-flow.