Language Servers delivery mechanism

[gazarenkov]

Goal: to implement and document mechanism for LS delivery using Che entities which:

• Is unified and documentable
• Use LS written by third party provider using any language (define and well-document possible conditions and limitations)
• Support LS deployed in standalone container usecase.

Presumably LS will be:

• declared as a Workspace's Server with meta-information enough to identify it as an LS, identify language(s) it serves etc
• Pre-deployed as a software inside image or an installation script inside recipe script or Che installer (as usual Server so)
• Normally be accessible from other machines (containers) running in WS
• accessible from outside via dedicated (proxying) server(s), not directly (to be able to combine LS-es and to give the access only via Che's authorization system)

So, to add Language Server one needs to add it as a Che Server with special set of attributes, like:

• languageServer=[languages]
• watchDirectories=[paths]
• matchPatterns=[regexps]

Subissues to implement:

• Add attributes field into ServerConfig and Server model objects - Add attributes field into ServerConfig and Server model objects #7560
• Add an ability to make Servers of LSs non-accessible for non-authenticated access from external network - Add an ability to make Servers of LSs non-accessible for non-authenticated access from external network #7561
• Provide JSON-RPC service for Language Service Communications Provide JSON-RPC service for Language Service Communications  #7582

[slemeur]

@gazarenkov : We already have an epic for that: #6792

[tsmaeder]

Why would the language servers be accessible from outside the workspace?

[garagatyi]

It won't. We will add internal server concept that may be treated by the infra in some special way. In case of Docker, it will be accessible from the workspace docker network only. Pretty the same behavior will be used for OpenShift (access by Service, not Route).