-
Notifications
You must be signed in to change notification settings - Fork 136
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* Add v3 xDS support This commit adds support for the v3 xDS transport as well as support for storing and serving v3 resources out of the resource cache. Note that resource versions and xDS transport version are decoupled to provide a migration path to v3. End users can decide to generate v3 resources and serve them over v2 transport during migration, or continue to generate v2 resources and serve them over v3 transport. For implementation simplicity, it is not possible to generate a combination of v2 and v3 resources in the control plane, which would require either up or down conversion. Signed-off-by: Michael Puncel <mpuncel@squareup.com> * PR comments: move type URLs to their own static class. Fix broken javadoc link. Use method overloading instead of different names for v2 vs v3 node hash Signed-off-by: Michael Puncel <mpuncel@squareup.com> * PR comments: use package names to differentiate v2 and v3 cache types Signed-off-by: Michael Puncel <mpuncel@squareup.com> * put tests in v2 and v3 packages Signed-off-by: Michael Puncel <mpuncel@squareup.com> * rename v2 onStreamRequest callback, remove default implementation Signed-off-by: Michael Puncel <mpuncel@squareup.com> * rename onStreamRequest on DiscoveryServerCallbacks Signed-off-by: Michael Puncel <mpuncel@squareup.com> * DRY most of the DiscoveryServerCallbacks implementations in integration tests Signed-off-by: Michael Puncel <mpuncel@squareup.com> * make v3 transport integration tests also use v3 resource version Note that there are not tests that cover a different transport version from resource version in the interest of not doubling the number of integration tests. Signed-off-by: Michael Puncel <mpuncel@squareup.com> * update README and add v2 -> v3 guide Signed-off-by: Michael Puncel <mpuncel@squareup.com>
- Loading branch information
Showing
60 changed files
with
5,371 additions
and
782 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,41 @@ | ||
# Migrating from xDS v2 to v3 | ||
|
||
To faciliate migrating from the v2 xDS APIs to v3, this repo supports both the | ||
v2 and v3 gRPC transports, with each transport supporting type URL rewriting of | ||
DiscoveryResponse to whatever version the client requests with | ||
api_resource_version. | ||
|
||
The migration requires care - for example, using v3-only fields too soon or trying to use | ||
deprecated v2 fields too late can cause Envoy to reject or improperly apply config. | ||
|
||
### Recommended Sequence | ||
|
||
This section assumes you have sufficient control over Envoy sidecar versions that you do | ||
not need to run v2 and v3 simultaneously for a long migration period. | ||
|
||
1. Make sure your oldest Envoy client supports final v2 message versions. | ||
2. | ||
1. Ensure your control plane is not using any deprecated v2 fields. | ||
Deprecated v2 fields will cause errors when they are translated to v3 | ||
(because deprecated v2 fields are dropped in v3). | ||
2. Configure a V3DiscoveryServer alongside the V2DiscoveryServer in your | ||
control plane. You can (and should) use the same (v2) Cache implementation | ||
in both servers. | ||
3. Deploy all Envoy clients to switch to both the v3 transport_api_version and | ||
resource_api_version in each respective xDS configs. As this happens, the V3DiscoveryServer | ||
will be translating your v2 resources to v3 automatically, and the V2DiscoveryServer will | ||
stop being used. | ||
4. | ||
1. Rewrite your control plane code to use v3 resources, which means using | ||
V3SimpleCache (if you use SimpleCache). You may now start using v3-only | ||
message fields if you choose. | ||
2. Drop the V2DiscoveryServer. | ||
|
||
### Alternative | ||
|
||
Another possible path to the one above is to switch to generating v3 in the | ||
control plane first (e.g. by using V3SimpleCache) and then deploying Envoy | ||
clients to use v3 transport and resource versions. | ||
|
||
This approach requires care to not use new V3-only fields until the client side | ||
upgrade is complete (or at least understand the consequences of doing so). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.