Sidecar Injection is tightly coupled with implementation -> Envoy

[naqvis]

Please describe the Improvement and/or Feature Request

current implementation of mutatingWebhook.createPatch is tightly coupled with envoy implementation, thus making it difficult to extend OSM for others reference implementations.

Can you please abstract out Injector functionality so that it is no longer implementation specific?

https://github.com/openservicemesh/osm/blob/30e53621b6895b0eb0d8ded24a7fb10226a38004/pkg/injector/patch.go#L28-L58

Scope (please mark with X where applicable)

• New Functionality [ ]
• Install [ ]
• SMI Traffic Access Policy [ ]
• SMI Traffic Specs Policy [ ]
• SMI Traffic Split Policy [ ]
• Permissive Traffic Policy [ ]
• Ingress [ ]
• Egress [ ]
• Envoy Control Plane [ ]
• CLI Tool [ ]
• Metrics [ ]
• Certificate Management [ ]
• Sidecar Injection [X ]
• Logging [ ]
• Debugging [ ]
• Tests [ ]
• CI System [ ]
• Demo [ ]
• Project Release [ ]

Possible use cases

Abstraction will help/enable other reference implementations.

[trstringer]

Thank you for opening this issue! What other proxy are you looking to use with OSM? At the moment we only support Envoy and have no current plans for any other sidecar proxy support.

[naqvis]

Thank you @trstringer. Doing our exploration phase we identified that OSM is vendor neutral and offers extension point for other control plane and/or sidecars proxies. We are planning to setup a PoC to implement OSM control plane by using Pipy.

[trstringer]

In regards to OSM, the control plane makes up almost the entire solution that is OSM specific. Therefore if you were to use another control plane, and keep the data plane as Envoy, then it would quickly resemble a different service mesh solution. Is that what your desire is?

And also, is there a gap in the OSM control plane that we could address, instead of using a different control plane?

[naqvis]

Sorry for the confusion. By control plane in my previous message was meant to say proxy control plane (highlighted in red rectangle).

OSM open & pluggable architecture with support of SMI open doors for extensibility, and we (Pipy team) are planning to run a PoC to plug Pipy as OSM data plane (similar to OSM reference implementation of envoy) to bring Pipy light-weight, programmable, ARM ready attributes into OSM scope.

[naqvis]

Adding to previous message. We have been able to successfully implement Pipy as a Proxy Control Plane. We have successfully executed 92% of E2E test cases on both AMD64 and ARM64 architecture while remaining 8% were ignored for time-being and we will continue working on them.

Source code is available at fork of osm at flomesh-io/osm under branch v1.1.0-arm

Snapshot of test cases and execution status. One highlighted in yellow are the ones which are ignored/pending:

[github-actions[bot]]

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.

[naqvis]

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.

Please keep it opened, as we are in the process of drafting a proposal to decouple data-plane interface from vendor specific implementation.

[naqvis]

Separate issue https://github.com/openservicemesh/osm/issues/4874 has been raised with detailed proposal

[github-actions[bot]]

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.

[steeling]

@naqvis you may be interested in https://github.com/openservicemesh/osm/pull/5109, which does some of the decoupling you're requesting

[naqvis]

@naqvis you may be interested in #5109, which does some of the decoupling you're requesting

Thanks @steeling. I'll definitely take a look

[github-actions[bot]]

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[bot]]

Issue closed due to inactivity.