search

envoyproxy / java-control-plane

Java implementation of an Envoy gRPC control plane
Apache License 2.0
293 stars 136 forks source link

Envoy v3 API support #126

Closed bartebor closed 4 years ago

bartebor commented 4 years ago

With Envoy v1.13.0 release v2 API became deprecated and we need to move on to v3. Is there any schedule on this?

snowp commented 4 years ago

Nobody is actively working on it as far as I'm aware, help would be appreciated.

baojr commented 4 years ago

What's involved with this? Do we just need to replace references to v2 API classes with their v3 counterparts?

snowp commented 4 years ago

@jyotimahapatra has been doing this fwork for go-control-plane, he might be able to comment on what work was done there. There is also various conversations happening around making the V3 flip easier, so the work required might change as that lands, e.g. https://github.com/envoyproxy/envoy/issues/10776.

jyotimahapatra commented 4 years ago

I did some work in go-control-plane to auto generate v3 code . There have been some conversations around v3 here, here.

mpuncel commented 4 years ago

I've been taking a stab at a PR.

My approach has been to try to do as much code reuse as possible, and also try to make the v4 upgrade as painless as possible. This comes at a tradeoff of unconstrained generics a few places in the codebase, but I'm also trying to not expose as much of that to callers to keep the complexity contained.

I'm also making a few assumptions that make the implementation easier, and would appreciate feedback on whether these assumptions make sense.

1) I'm not supporting mixing v2 and v3 resources into a Snapshot. There will be a V2Snapshot type, and a V3Snapshot type, and a V2SimpleCache and a V3SimpleCache that accept them, respectively. This means that control plane implementations will need to migrate from v2 to v3 in one fell swoop. For us it'd definitely be a big task, but I'm not sure how much value there is in a gradual migration. Enabling a gradual migration would require translating from v2 to v3 and merging or vice versa, addressing potential conflicts, and probably more configuration options. I think it makes things simpler to assume it's all V2 or all V3 and enforce that in the API. 2) Both cache implementations will respond to the v2 or v3 xDS transport protocol, but will not do any translation of messages. This means you can switch to the v3 cache and deploy it and nothing will change (as long as the data planes all support v3). Then you can migrate the data planes to v3. The other order should work as well. 3) This will break existing callers, even if they don't move to v3. This is for consistency, e.g. the caches will be called V2SimpleCache and V3SimpleCache, so will require a bit of code change to fix compilation. This is going to happen anyway eventually when V2 support is eventually dropped, and I think having versions in the names makes things clearer.

Regarding timeline, it's hard to say when this PR will be done. I'm just commenting to drive discussion, but I don't want to block everyone else if I have trouble scheduling the time for it, so let me know if it would be useful for me to put up a work-in-progress PR for others to look at. I also won't mind if someone else implements in parallel and beats me :)

mpuncel commented 4 years ago

I put up my PR https://github.com/envoyproxy/java-control-plane/pull/140#pullrequestreview-455805657.

pzmi commented 4 years ago

Since #140 is merged I guess this can be closed.