serving-operator icon indicating copy to clipboard operation
serving-operator copied to clipboard

support for Gloo?

Open ilackarms opened this issue 5 years ago • 3 comments

hi there! recently discovered this project and it looks really cool.

solo.io implemented a reconciler for clusteringress (knative serving's integration point for proxies) to integrate our api gateway/ingress Gloo.

Gloo is actually a viable alternative to Istio as an installation option for serving https://github.com/knative/docs/blob/master/docs/install/Knative-with-Gloo.md

anyway, my question comes down to this: if we were interested in adding support for Gloo-based installs of Knative, would that be possible given the current implementation of the operator? would the maintainers be open to a contribution like that?

ilackarms avatar Jun 21 '19 19:06 ilackarms

Right now the operator is tied to istio. We agreed early on though that we do not want to manage or require a data plane as part of this operator and we expect users will need to do some pre-configuration to bring their own.

Given this I'd expect there shouldn't be a need to add things to the operator for Gloo support but rather remove our istio assumptions. This is a bit far away though - we don't even have a CI job working yet :)

greghaynes avatar Jun 21 '19 20:06 greghaynes

Additionally, it may be useful to have a Gloo operator as well to get Gloo installed successfully in the cluster.

I'm not sure whether everyone agrees with this, but my preference would be for the operator to be able to detect the presence of compatible routing layers (Istio/Gloo/etc), and automatically select the correct one. Manual configuration would still be available for the cases where the operator can't detect the right environment, or where there is more than one routing option installed.

On Fri, Jun 21, 2019 at 1:43 PM Gregory Haynes [email protected] wrote:

Right now the operator is tied to istio. We agreed early on though that we do not want to manage or require a data plane as part of this operator and we expect users will need to do some pre-configuration to bring their own.

Given this I'd expect there shouldn't be a need to add things to the operator for Gloo support but rather remove our istio assumptions.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/knative/serving-operator/issues/25?email_source=notifications&email_token=AB4XEN6POSRKUT6YIJPKSIDP3U4QVA5CNFSM4H2UNOEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYJRIQA#issuecomment-504566848, or mute the thread https://github.com/notifications/unsubscribe-auth/AB4XEN2432B5ZO5TBAGYU5DP3U4QVANCNFSM4H2UNOEA .

-- Evan Anderson [email protected]

evankanderson avatar Jun 23 '19 18:06 evankanderson

if the operator could simply install Knative components without additionally installing or requiring istio, that would be ideal. whatever an outside/community opinion is worth, +1 to detection

ilackarms avatar Jun 24 '19 15:06 ilackarms