Leverage XDS v3 protocol when limited by SMI

[draychev]

SMI provides us with a rich set of primitives to configure our service mesh. SMI does not cover the entire set of features Envoy proxy provides. A service mesh operator, who needs functionality which exists in Envoy but is not serviced via SMI would reach a cliff. To provide a way beyond what SMI currently offers we need to provide the ability for an OSM user to switch to xDS v3 protocol directly.

One such example is the use of a new CRD to configure Envoy circuit breaking - example is in our ./experimental folder.

We need to develop the example we have further to provide more of xDS v3 directly configurable via a CRD.

[nojnhuh]

@draychev Are there any more PRs or issues related to this in flight? If so, could you keep linking back to this issue so we can keep track of those?

[steeling]

@shashankram thoughts on closing this out? This seems like an abstract support more features bug, vs something concrete.

If it has concrete features we can call those out in individual issues.

[shashankram]

@steeling I don't have a strong opinion on whether we want to repurpose this issue or create a new issue to allow a mechanism to directly configure Envoy. This is an extremely high level ask, which likely needs a lot of thought to design a mechanism that will not conflict with existing policy APIs.

Also, note that this issue was filed 2 years ago, but we haven't prioritized this, so it's likely not something we have considered pressing. Feel free to close this one if you think it's better to have a more concrete issue pertaining to custom Envoy configs.

[github-actions]

This issue will be closed due to a long period of inactivity. If you would like this issue to remain open then please comment or update.

[github-actions]

Issue closed due to inactivity.