che: It is not possible to run more than one Che 7 workspace at a time

What we do now:

• VS Code and Theia brokers:
  • Create endpoint with name port5690
  • Create Env Var to pass info about the plugin to theia container with value ws://port5690:5690
• Che master creates k8s service with name equal to the endpoint name
• Che plugin broker (the first one that uses tar.gz)
  • Gets endpoint from the configuration YAML
• Che master creates k8s service with a name equals to the endpoint name for this broker

What options we have to allow running several workspaces in a single k8s namespace:

1. Prefix with workspace ID service on wsmaster

• VS Code and Theia brokers:
  • Create endpoint with name port5690
  • Create Env Var to pass info about the plugin to theia container with value (brokers know that endpoint will have one name but would be discoverable only after prefixing) ws://workspace12345678port5690:5690
• Che master creates k8s service with a name that consists of workspace ID and endpoint name workspace12345678port5690​
• Che plugin broker (the first one that uses tar.gz)
  • Gets endpoint from the configuration YAML, e.g. theia
• Che master creates k8s service with a name that consists of workspace ID and endpoint name workspace12345678theia​

Pros:

• simple to implement Cons:
• Brokers behavior is not consistent: if discoverability is needed endpoint should have a name that differs from the name used for service discovery
• if we expose these k8s services over API as Che servers (we don’t at the moment) then server name would be also inconsistent either with the endpoint or k8s service
• if we want to move brokering process from workspace start to registry than we can’t statically evaluate this since we don’t have workspace ID. We will need to have a placeholder in the env var.

1. Let brokers prefix endpoint with workspace ID themselves:

• VS Code and Theia brokers:
  • Create endpoint with name workspace12345678port5690
  • Create Env Var to pass info about the plugin to theia container with value ws://workspace12345678port5690:5690
• Che master creates k8s service with name equal to the endpoint name
• Che plugin broker (the first one that uses tar.gz)
  • Gets endpoint from the configuration YAML, e.g. theia
• Che master creates k8s service with a name that consists of workspace ID and endpoint name workspace12345678theia

Pros:

• brokers behavior is consistent: if service discovery is needed broker uses the same name for discovery and endpoint
• if we expose these k8s services over API as Che servers (we don’t at the moment) then server name would be also consistent with endpoint and k8s service Cons:
• if we want to move brokering process from workspace start to registry than we can’t statically evaluate this since we don’t have workspace ID. We will need to have a placeholder in the env var.
• If some broker implementation would not prefix endpoint with workspace ID multiple workspaces with the same plugin would not start. We don’t actually have third-party broker implementation and this can be avoidable by reading docs. Doesn’t seem a problem for me now.

1. Make service discovery depend on env vars instead of predictable service name:

• Make Theia support a new way of discovering remote plugins runners:
  • Instead of just a link by which remote Theia is accessible use value env:SOME_ENV which means that actual value is written in SOME_ENV
• VS Code and Theia brokers:
  • Create endpoint with name port5690
  • Create Env Var with value env:CHE_PLUGIN_ENDPOINT_port5690
• Che master:
  • Creates k8s service with a name that consists of workspace ID and endpoint name workspace12345678port5690​
  • Inserts following env var into all workspace containers: CHE_PLUGIN_ENDPOINT_<endpoint name> in our case CHE_PLUGIN_ENDPOINT_port5690 with value <endpoint protocol>😕/<workspace ID><endpoint name>:<endpoint port><endpoint path>
• Che plugin broker (the first one that uses tar.gz)
  • Gets endpoint from the configuration YAML, e.g. theia
• Che master creates k8s service with a name that consists of workspace ID and endpoint name workspace12345678theia and inserts env var CHE_PLUGIN_ENDPOINT_theia with value http://workspace12345678theia:3000 so if some plugin wants to connect to it it can read env var with a predictable name

Pros:

• Consistent look of endpoint and server
• Allows us to statically evaluate plugins config in the registry instead of on workspace start
• Doesn’t make broker knows about prefixing which is not broker responsibility
• Simple changes in brokers Cons:
• more complex change
• require the addition of a new way of discovering remote plugin runner in Theia if env var value is env:SOME_ENV then read the value from SOME_ENV

I would go with option 3 and here is how to do it in an iterable way:

1. Disable discoverability in endpoints that don’t need it at the moment theia, exec sidecar
2. Make VS Code and Theia brokers generate endpoints with workspace ID OR some random chars
3. at this stage it would be possible to start several workspaces at the same time
4. Add support of env:SOME_ENV to Theia
5. Rework brokers to leverage this feature.

DONE!