A30: xDS v3 Support #189

markdroth · 2020-06-23T22:51:24Z

No description provided.

A30-xds-v3.md

ejona86 · 2020-06-26T15:38:26Z

A30-xds-v3.md

+request v2 resources, but it's fine for the server to send us either v2
+or v3 resources.  Similarly, if we're using the v3 transport protocol,
+we will request v3 resources, but it's fine for the server to send us
+either v2 or v3 resources.


Except that the server doesn't know that the client supports v2. When we add support for v3.1, we would drop support for these v2 resources and newer clients would break.

Again, because of make-before-break, I think this is okay. The client will still deserialize the resources as whatever version it wants, regardless of which version the server used when serializing.

There is a mapping from v2 resource names to v3 resource names. You don't just look at the message name, "oh, this ends with Listener, let's assume it is an envoy.config.listener.v3.Listener". The version is part of the Any and type_url. When the client drops v2 support, are you saying it will keep the v2→v3 message name mapping and continue supporting v2 protos? That is not at all obvious to me.

I see what you're saying. I agree that this is a concern.

I see two possible options here:

We continue to accept the v2 type_url even after we drop v2 support, within some bounds (e.g., maybe we could say that we will continue to support v2 type_urls for as long as we're supporting v3, just to allow this type of transition).

Stick with the plan of dropping v2 support and just document the fact that servers can use this as a transition mechanism but need to stop sending v2 protos to v3 clients before they can upgrade to a version of gRPC that does not have v2 support.

My inclination is to go with (2), but I'd be willing to do (1) if there's a need for it.

@htuch, how is Envoy handling this?

As above. The idea is that mixed version support only exists during the 1 year transition period and is only there for supporting rollouts where they may be mixed client/server features as an ephemeral process.

I've added a paragraph clarifying that this is just intended for use as a rollout strategy, not something that can be assumed in the general case.

A30-xds-v3.md

htuch · 2020-06-29T01:03:32Z

A30-xds-v3.md

+It will assume that all servers speak version N-1, and there will be a
+server feature defined in the bootstrap file (see below) to tell it that
+the server supports version N.  When speaking to the server, gRPC will use
+the highest version that is common to both itself and the server.


The minor versioning proposal features version negotiation, should this be the preferred mechanism all things being equal?

The minor versioning proposal says that there will be some mechanism for version negotiation, but it does not actually define what that mechanism will be. The current text of the proposal suggests using context params, but in offline conversation, you and I and Matt agreed that that won't actually work due to the exact-match semantics of context_params. I believe that where we left this was that when someone actually gets around to implementing the minor version proposal, they will need to come up with a concrete proposal for version negotiation. So I think that how this works is an open question, and I don't want to say anything about that here until we have a concrete proposal to evaluate.

It is also worth noting that the way our implementation is going to work, the version configured in the bootstrap file is effectively the transport version, not the resource version, whereas the version negotiation mechanism is by necessity primarily about resource version. As an example, the version negotiation mechanism probably won't be usable to control things like the "xds transport next steps" design that you're currently working on implementing, because the client needs to know whether to use it before it sends the initial request containing its supported versions. This is another reason why I believe it would be beneficial to consider the transport version and the resource version independently: in terms of mechanism, transport changes are generally going to be configured via client-side configuration rather than version negotiation.

A30-xds-v3.md

htuch · 2020-06-29T01:10:42Z

A30-xds-v3.md

+field being added in https://github.com/envoyproxy/envoy/pull/11754 to
+specify the transport version of LRS.  However, since this field will exist
+only in xDS v3, this would still not provide a clean way to specify use
+of LRS v3 while using xDS v2.


I think maybe we could add this to v2. The v2 freeze is there to encourage folks to move to v3, if we're adding a field to explicitly make this easier, then why not.

Sounds good. I've sent you envoyproxy/envoy#11824.

A30-xds-v3.md

htuch · 2020-07-01T15:42:31Z

A30-xds-v3.md

+request v2 resources, but it's fine for the server to send us either v2
+or v3 resources.  Similarly, if we're using the v3 transport protocol,
+we will request v3 resources, but it's fine for the server to send us
+either v2 or v3 resources.


As above. The idea is that mixed version support only exists during the 1 year transition period and is only there for supporting rollouts where they may be mixed client/server features as an ephemeral process.

htuch · 2020-07-01T15:43:45Z

A30-xds-v3.md

+  call this the *resource version*.
+
+When gRPC uses v3 to talk to a server, the primary thing that it is
+choosing is the transport protocol version, not the resource version.


One consideration worth noting is that the transport version only can currently change based on major version. There is no minor/patch in the gRPC endpoint.

Yeah, I realize that. But this section of the doc is specific to the v2->v3 transition, and in this case, the major version number is the only relevant part.

A30-xds-v3.md

ejona86 · 2020-07-01T18:36:33Z

A30-xds-v3.md

+
+Note that the ability to accept resource versions that are different
+than what was requested is only intended for use as a rollout strategy
+during transitions where the management server has some a prior


"a priori" or "prior"

dfawley

Looks good, just one thing to consider.

dfawley · 2020-07-13T21:21:15Z

A30-xds-v3.md

+
+### Version Support Policy
+
+gRPC's policy will be to support two versions of xDS at any given time.


Is this "at most two versions"? Or "exactly two versions"? If v4 isn't released for 5 years, will we support v2 for that long?

The current plan is to have one new version per year, so I think this distinction isn't important. If the version release schedule changes, then we can change our policy at that point.

That sounds fair. It does seem likely there will be an xDS version bump every time there is an opportunity to do so.

dfawley · 2020-07-14T15:55:21Z

A30-xds-v3.md

+
+### Version Support Policy
+
+gRPC's policy will be to support two versions of xDS at any given time.


That sounds fair. It does seem likely there will be an xDS version bump every time there is an opportunity to do so.

markdroth added 2 commits June 23, 2020 15:50

A30: xDS v3 Support

cf5105a

address TODO about LRS transport version

661946b

markdroth marked this pull request as ready for review June 25, 2020 17:51

markdroth requested review from ejona86 and dfawley and removed request for ejona86 June 25, 2020 17:51

markdroth changed the title ~~WIP: A30: xDS v3 Support~~ A30: xDS v3 Support Jun 25, 2020

add discussion link and update status

ab75c4d

ejona86 reviewed Jun 26, 2020

View reviewed changes

address review comments

682415f

htuch reviewed Jun 29, 2020

View reviewed changes

sanjaypujare reviewed Jun 29, 2020

View reviewed changes

A30-xds-v3.md Show resolved Hide resolved

sanjaypujare reviewed Jun 29, 2020

View reviewed changes

A30-xds-v3.md Outdated Show resolved Hide resolved

sanjaypujare reviewed Jun 29, 2020

View reviewed changes

A30-xds-v3.md Show resolved Hide resolved

address reviewer comments

c62918e

htuch reviewed Jul 1, 2020

View reviewed changes

ejona86 reviewed Jul 1, 2020

View reviewed changes

A30-xds-v3.md Outdated Show resolved Hide resolved

address reviewer comments

689ed7f

ejona86 approved these changes Jul 1, 2020

View reviewed changes

fix typo

cf06320

markdroth mentioned this pull request Jul 9, 2020

xDS v3 support grpc/grpc#23281

Merged

dfawley reviewed Jul 13, 2020

View reviewed changes

dfawley approved these changes Jul 14, 2020

View reviewed changes

markdroth merged commit 2ffadbb into grpc:master Jul 23, 2020

markdroth deleted the xds_v3 branch July 23, 2020 21:12

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

A30: xDS v3 Support #189

A30: xDS v3 Support #189

markdroth commented Jun 23, 2020 •

edited

Loading

ejona86 Jun 26, 2020

markdroth Jun 26, 2020

ejona86 Jun 29, 2020

markdroth Jun 30, 2020

htuch Jul 1, 2020

markdroth Jul 1, 2020

htuch Jun 29, 2020

markdroth Jun 30, 2020

htuch Jun 29, 2020

markdroth Jun 30, 2020

htuch Jul 1, 2020

htuch Jul 1, 2020

markdroth Jul 1, 2020

ejona86 Jul 1, 2020

markdroth Jul 1, 2020

dfawley left a comment

dfawley Jul 13, 2020

markdroth Jul 13, 2020

dfawley Jul 14, 2020

dfawley Jul 14, 2020


		### Version Support Policy

		gRPC's policy will be to support two versions of xDS at any given time.

A30: xDS v3 Support #189

A30: xDS v3 Support #189

Conversation

markdroth commented Jun 23, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dfawley left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

markdroth commented Jun 23, 2020 •

edited

Loading