Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid the need to set userland-proxy #11018

Closed
benoitf opened this issue Aug 31, 2018 · 13 comments
Closed

Avoid the need to set userland-proxy #11018

benoitf opened this issue Aug 31, 2018 · 13 comments
Assignees
Labels
kind/enhancement A feature request - must adhere to the feature request template.

Comments

@benoitf
Copy link
Contributor

benoitf commented Aug 31, 2018

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

@benoitf benoitf added kind/enhancement A feature request - must adhere to the feature request template. team/platform labels Aug 31, 2018
@l0rd l0rd mentioned this issue Aug 31, 2018
57 tasks
@garagatyi
Copy link

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
Copy link
Contributor Author

benoitf commented Mar 28, 2019

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

@garagatyi
Copy link

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
Copy link
Contributor Author

benoitf commented Mar 28, 2019

@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
Copy link
Contributor Author

benoitf commented Mar 28, 2019

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

@l0rd
Copy link
Contributor

l0rd commented Mar 28, 2019

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

@garagatyi
Copy link

@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
Copy link
Contributor

l0rd commented Mar 29, 2019

@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 l0rd changed the title Detect / ensure routes of ws.next are possible on underlying platform / infrastructure Avoid the need to set userland-proxy Apr 7, 2019
@l0rd
Copy link
Contributor

l0rd commented Apr 7, 2019

@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 l0rd mentioned this issue Apr 7, 2019
@l0rd
Copy link
Contributor

l0rd commented Apr 7, 2019

This is related to #11146 (comment) as well

@davidfestal
Copy link
Contributor

Yes, I plan to work on this during next Sprint

@ibuziuk
Copy link
Member

ibuziuk commented May 21, 2019

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

@ibuziuk
Copy link
Member

ibuziuk commented May 21, 2019

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

@ibuziuk ibuziuk closed this as completed May 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement A feature request - must adhere to the feature request template.
Projects
None yet
Development

No branches or pull requests

7 participants