Avoid the need to set userland-proxy

[benoitf]

Description

When trying wskeleton workspace on my minishift, endpoints defined in the plug-ins were failing.

It was due to lack of userland-proxy=false arg provided to my minishift instance.

But there was no report from wsmaster/dashboard/IDE/etc that my system was misconfigured and that I will have failures.

There should be a way to check the platform is OK when running Eclipse Che on top of it to avoid this kind of issues.

reference #8134

Reproduction Steps

1. Use of minishift to deploy che without changing some internal parameters.
2. Try to access port of a tooling container using CHe plugin endpoint name and port.

Expected

Port is reachable

Actual

Port is unreachable

[garagatyi]

Taking into account that Che can run on multi-node k8s cluster, so this issue can appear on some particular node, and that Che might not be allowed to run anything without user initiating the process it can be hardish to tackle this issue in general without affecting complexity of the workspace start and and workspace start time.
Possible option is to include in the logic of Theia (CheTheia) that if connection to Theia plugin sidecar instance (please let me know if we have a set term for this Theia instance) fails with specific pattern that we see in such a case Theia should report that to the user

[benoitf]

logic should not be in the editor (as we can select different editors)

[garagatyi]

If Theia fails to connect to its slave it is Theia specific use-case, even though it is caused by infra specific use-case. And it needs to be properly handled by Theia.
Tackling this on infra side could be way trickier and not cover corner cases

[benoitf]

@garagatyi I will work on something like displaying a notification if for example after XXX attempts the websocket is still not able to connect to some endpoint.

but:
if plug-ins are really send to each sidecar (last step on how to deploy plug-ins)

• Theia is reconnecting to the slaves automatically. If there is an infra problem (websocket issue) then the plug-in would not show up is plug-ins view list.
• if at some point websocket connection is working then it will display the plug-in in the list.

[benoitf]

but I don't want that theia should be responsible of doing the lack of the platform.

[l0rd]

exec plugin is working even if userland-proxy=false is not set. Can't we make other sidecars working as well?

[garagatyi]

@l0rd exec connects to ingres/route exposed as server. Theia uses service.
Since we are generating access rules on brokering phase when ingress/route URL is not yet known we will have to implement another approach to use routes for connecting plugins.
Another option is what @benoitf suggested - use localhost and put plugins to separate locations in sidecars instead of sharing /plugins between Theia and slaves

[l0rd]

@garagatyi thanks for the explanation. What is clear to me is that we can and should avoid asking users to set the docker userland-proxy option. That's because setting the userland proxy may require to minishift/minikube delete (if the user had already start minishift/minikube). That's something that may discourage users to deploy Che and it's not acceptable.

Not sharing plugins between theia and sidecars looks the best solution and becomes more critical now.

cc @slemeur

[l0rd]

@davidfestal are you working or do you plan to work on this issue? If you do please assign it to yourself.

I believe that to solve this issue we need to use localhost and implement the 3rd option mentioned by @benoitf in this comment.

[l0rd]

This is related to #11146 (comment) as well

[davidfestal]

Yes, I plan to work on this during next Sprint

[ibuziuk]

I believe we need to update Che server to use v0.17.1version and than close this issue as Done

[ibuziuk]

Just figured out that Che master points to the v.0.17 and will resolve latest micro version automatically.
Closing as done. Will be a part of the 7 beta 5 release.

https://github.com/eclipse/che/blob/master/assembly/assembly-wsmaster-war/src/main/webapp/WEB-INF/classes/che/che.properties#L555