SPIKE: How could/should we start up docker container(s) from the extension for the language server

[michaeltlombardi]

We need to figure out how to incorporate the docker containers for the language server more seamlessly for users of the extension.
This issue is for documenting how the docker extension is doing things and how we can adapt those lessons for ourselves.

AS AN extension user
I WANT to be able to start the language server as
  a docker container without leaving the extension
SO THAT I can switch out the language server details
  I am writing Puppet code against without having to
  run commands externally and then change internal 
  settings.

[snoopdouglas]

+1, there are various reasons I don't want to install the language server unconfined.

[glennsarti]

@snoopdouglas what do you mean by "unconfined" ?

[snoopdouglas]

I mean on my workstation's Linux, without being in a container.

[michaeltlombardi]

So, I've been looking into this and I think the sanest way to do this is to steal reuse code from the docker extension, which is licensed under MIT.

That extension has a command for starting a container which the user needs to select from their menu and choose to run interactively or in the background. We'll pretty much always want to run it in the background, I think, so we could reduce some of the complexity - but when it starts, it starts up the container with the port(s) automatically mapped.

That code relies on a helper utility file which we might be able to just copy, or snip useful parts from - our use case will be a bit simpler, I think.

Proposal

• Copy the helper file into our project
• Modify to point statically at our docker image with the latest tag
• Bring in the port mapping and container starting code to that file.
• Add configuration settings of some sort to make this a toggle (without any other configuration for the time being)
• Get the extension working while pointing to the language server running as a docker container with the default port exposed.

Initially, the important thing is to be able to spin up the language server in a container and use it. We can fiddle with making this more extensible in the future, I think - allowing users to specify alternate images or tags.

A future option would be to add commands to start/stop/restart the language server container, possibly - but out of scope for this initial work in my opinion.

[jpogran]

I believe this spike ticket is complete. Issue #375 created to track progress of implementation