3.5 decision making for alpha/beta/experimental feature stability

[gyuho]

We either need promote the stability of these features or keep it as it is with changes to CHANGELOG:

• gRPC gateway only supports /v3 endpoint.
• Change etcd --experimental-enable-v2v3 flag to etcd --enable-v2v3; v2 storage emulation is now stable.
• etcd --enable-v2v3 flag is now stable.

[ptabor]

Do we have active user's of V2 APIs that cannot stay on 3.5 ?

Options:

1. 3.5 is the last release that exposes V2 apis at all.
2. 3.5 is the last release that exposes V2 apis on separated v2 storage. Starting from 3.6 v2v3 bridge is the only way to access V2 APIs.

[hexfusion]

Do we have active user's of V2 APIs that cannot stay on 3.5 ?

Speaking for Red Hat all supported v2 store is isolated to release-3.2 (besides membership as outlined in #12913)

My vote is we take a harder line approach towards 1. The cost of support for this API has taxed maintainers (thanks Piotr + others). If folks would like to defend option 2 I think we would like to see that need directly from the community. If we send out a notice through typical channels and provide time for community input I guess that input can drive the decision. From that input if organizations or users feel strongly that support should continue. Then perhaps they can own part/all of this maintenance.

Thanks for bringing up this subject.

[gyuho]

3.5 is the last release that exposes V2 apis at all.

etcd/server/etcdmain/help.go

Lines 125 to 126 in c46e96d

	--enable-v2 '` + strconv.FormatBool(embed.DefaultEnableV2) + `'
	Accept etcd V2 client requests.

https://github.com/etcd-io/etcd/blob/release-3.4/etcdmain/help.go#L119-L120

I don't think we need remove v2 code until etcd v4. It's still used internally for health checks. We already disabled v2 API by default in v3.4. While we mark v2v3 API stable, we can mark --enable-v2 to something like enable-legacy-v2>

[ptabor]

@gyuho: Do I understand correctly that you are postulating not decommissioning v2 store (backend) code in v3 completely ?

I find this storev2 code:

• significant source of complexity (partial redundancy of data between stores)
• cost during bootstrap (scanning of both -snap.db files and WAL log to find matching entries).
• gotches: etcdctl snapshot, etcdctl restore silently ignoring storeV2 content.

I don't think we have engineering capacity (and ideas for technical value added) to plan for V4 in foreseeable future.

As stated in #12913, 3.7 would be the release without v2store backend.

v2v3 needs to have capability to be mounted as 'root' if we need a drop-in-replacement to preserve the API.

[gyuho]

@ptabor As we discussed during the meeting, let's keep etcd --experimental-enable-v2v3 as experimental and deprecate for 3.7.

[ptabor]

The code changes backed by this decision were incorporated in:
#12940

[gyuho]

@hexfusion Can you help us with the grpc-gateway v3 promotion?