api/faq: add initial API versioning FAQ entries. #10829
Conversation
This patch seeds the FAQ with some initial Q+As around the API that have come up. Signed-off-by: Harvey Tuch <htuch@google.com>
|
CC @fuqianggao (you might want to review some of this for your current efforts) |
Signed-off-by: Harvey Tuch <htuch@google.com>
docs/root/faq/api/control_plane.rst
Outdated
| 1. Independent v2/v3 configuration generation pipelines. This is simple to understand but | ||
| involves significant duplication of code and can be expensive engineering wise. This may | ||
| work well if the API surface in use is small. | ||
| 2. Have the control plane use v2 canonically and mechanically transform v2 messages to their |
There was a problem hiding this comment.
From an experiment here it looks like we need some fixes in envoy to accept mixed responses in xds grpc responses.
There was a problem hiding this comment.
i might be wrong. Taking a closer look again to debug.
There was a problem hiding this comment.
Couldn't get it working yet.
Error after some more fixes to control plane code:
[2020-04-17 19:18:00.722][1209][debug][config] [source/common/config/grpc_mux_impl.cc:136] Received gRPC message for type.googleapis.com/envoy.config.cluster.v3.Cluster at version v0
[2020-04-17 19:18:00.722][1209][warning][config] [source/common/config/grpc_mux_impl.cc:139] Ignoring the message for type URL type.googleapis.com/envoy.config.cluster.v3.Cluster as it has no current subscribers.
Signed-off-by: Harvey Tuch <htuch@google.com>
There was a problem hiding this comment.
Thanks for doing this. This is a great start. I would suggest we ship and iterate. I do think that having some more guidance on how to actually perform the upgrade would be useful based on conversations that have been occurring in Slack, but we can add that later.
| @@ -0,0 +1,27 @@ | |||
| How do I support multiple xDS API major versions in my control plane? | |||
There was a problem hiding this comment.
In a follow up should we actually have a FAQ entry around a control plane doing an upgrade, even if they want to support a single version? There have been tons of questions about this and I wonder if we should provide some ideas/guidance/specifics especially when using go-control-plane? Thoughts? cc @kyessenov @jyotimahapatra @envoyproxy/maintainers @envoyproxy/api-shepherds
There was a problem hiding this comment.
Yeah, I think this has been quite thoroughly explored in istio/istio#19885. I will make a note to work on a followup; some of the advice will be conditional on items such as #10776 and #8421.
There was a problem hiding this comment.
Im not sure if istio/istio#19885 captures the scenario where the control plane is migrated to v3 and serves v3 responses to v2 requests by just changing the typeurl.
Since the lds/cds resource versions will be in bootstrap config, it will be very difficult to move our whole fleet to v3 without this solution.
I think go-control-plane integration tests can easily demonstrate such canonical migration scenarios.
This patch seeds the FAQ with some initial Q+As around the API that have come up. Signed-off-by: Harvey Tuch <htuch@google.com> Signed-off-by: pengg <pengg@google.com>
This patch seeds the FAQ with some initial Q+As around the API that have
come up.
Signed-off-by: Harvey Tuch htuch@google.com