Enabling multiple che 7 plugins results in workspace failure due to quota of service

[ibuziuk]

starting workspace with multiple plugins enabled on che.openshift.io results in service quota issue:

I believe it should be possible to repro with just 4-5 plugins enabled simultaneously

Currently quota of services = 15, should we consider increasing this figure - https://github.com/fabric8-services/fabric8-tenant/blob/master/environment/templates/fabric8-tenant-che-quotas.yml#L85

[ibuziuk]

@l0rd @slemeur WDYT ?

[l0rd]

The question is rather we need those 15 services...

[ibuziuk]

@l0rd yeah, this is a good point. AFAIK there were some talks/issues related to decreasing of the # of exposed services / routes as I recall

[garagatyi]

@ibuziuk would it be possible to get services list for this case on upstream Che? This would simplify investigation why we use so many services

[ibuziuk]

@garagatyi yeah, I can repro it by enabling those plugins:

no services are created AFAIK, quota is hit before svc creation request

[garagatyi]

But is there a way to reproduce services limit issue?

[ibuziuk]

@garagatyi yes, I was able to repro it by enabling those plugins #1371 (comment)

[garagatyi]

Tested with suggested config and was able to reproduce on upstream the amount of services. Workspace with editor and 9 plugins created 18! services.
Found with @sleshchenko the reason why we create so many services.
First of all we create 2 services for every plugin sidecar. This is caused by historical reasons. In particular, I had to add Che 7 functionality to Che 6 in an ad hoc manner because other maintainers weren't agree to add it directly to the main flow back when Che 7 wasn't a thing.
Now we can refactor services generation code a bit and reduce amount of services.
Another reason is that we create a service per workspace server (port) which is not needed in a case of a single pod. We could rework that to optimize services usage.
We could also not generate services for each plugin since they are in the same pod and can be accessed over localhost. AFAIK David was working on something like that. David, could we enable that on OSIO?

[garagatyi]

@davidfestal ^

[garagatyi]

Related eclipse-che/che#11452

[davidfestal]

This seems related to issue eclipse-che/che#11018 where the solution was to use localhost + port instead of the service name, in order to contact Theia / VSCode plugins. If we do that, we don't need a service anymore as @sleshchenko just said.

The good news is that there is already a new global option in the che-plugin-broker to use localhost instead of the service name. issue mentioned above was assigned to me and was mainly enabling this setting in upstream Che. So most of the work here would be to refactor the upstream Che service creation.

[garagatyi]

@ibuziuk how important this issue is? Should we take it as unplanned or wait for the next sprint?

[garagatyi]

@davidfestal but it would not work on minikube with userland proxy enabled, right?

[davidfestal]

@garagatyi TBH I'm not an expert of the userland proxy mode, but I seem to remember having it enabled though accessing from one container to another through localhost + port. I might be wrong though.

[ibuziuk]

Closing as fixed