Vscode-remote-release: Making the version check in remote-containers less restrictive

[wherka]

Hello,
as it stands ms-vscode-remote.remote-containers extension explicitly forbids any attempt to attach VSCode to the container when the docker daemon version detected is lower than the hardcoded value of 17.12.0

Here is the symptom:

This is what's on the server side in my case:

docker info
Server Version: 1.13.1

lsb_release -a
LSB Version: :core-4.1-amd64:core-4.1-noarch
Distributor ID: RedHatEnterpriseServer
Description: Red Hat Enterprise Linux Server release 7.7 (Maipo)
Release: 7.7
Codename: Maipo

oc version
oc v3.11.154
kubernetes v1.11.0+d4cacc0

This docker daemon installation comes with or is implied by OpenShift 3.x on RHEL 7.7, so that's not something I can change easily without nasty consequences on the OC side.

I know exactly what is wrong there and I know how to circumvent this to make it talk to even this old daemon. However, according to the license agreement I'm legally not allowed to do it as that's closed source:

https://ms-vscode-remote.gallerycdn.vsassets.io/extensions/ms-vscode-remote/remote-containers/0.148.0/1604006153365/Microsoft.VisualStudio.Services.Content.License

"7. SCOPE OF LICENSE. (...)
You may not:
* work around any technical limitations in the software;"

Just for your information: I did performed a quick test on how it would behave if the version reported by the server was higher(a little cheat on the docker client side) to verify if this restriction is really necessary.
It turned out every single aspect I needed was working perfectly well, so I reckon we should give people a chance to experiment with older versions should they require it.

Could you perhaps consider lifting this version check and popping up just a gentle warning, so the users who can upgrade the docker daemon can do the needful and these who cannot as myself can carry on working in a best effort mode please?

It would be also acceptable to have a default behaviour unchanged, but to have a possibility to override this check explicitly in the configuration.

Blocking the arbitrary versions of Docker is just not nice to us poor end users who cannot benefit from such a great extension otherwise. It is really sad :(
I really love working with remote-containers extension and it just breaks my heart seeing this popup - especially when I know most of the features and in fact all the features I care about will work just fine if you let me go past this version check.

Is there something you could perhaps consider please? I would really appreciate it.

Kind Regards,
Waldek

[chrmarti]

What do you get for docker version --format {{.Server.APIVersion}}?

[wherka]

@chrmarti : first of all - thanks a lot for picking it up so quickly! I really appreciate that.

Secondly, the details you've requested:
~/docker-windows-amd64.exe version --format {{.Server.APIVersion}}
1.26

~/docker-windows-amd64.exe version
Client:
Version: 20.10.0-dev
API version: 1.26
Go version: go1.13.15
Git commit: c20be83d6b
Built: Sat Nov 7 21:02:54 2020
OS/Arch: windows/amd64
Context: default
Experimental: true

Server:
Engine:
Version: 999.0.0
API version: 1.26 (minimum version 1.12)
Go version: go1.10.3
Git commit: 4ef4b30/1.13.1
Built: Fri Dec 13 01:48:25 2019
OS/Arch: linux/amd64
Experimental: false

You may notice from the console printout I'm faking the server version for now to allow VSCode connecting to the container. This is just a hack to check what is working and what is not. To be clear - this is not done on the extension, but by recompiling the docker client itself, so I believe I'm not breaching any license agreements there.
So far I've not encountered anything that renders the whole thing as unusable, so I suggest we should try to lower the minimum requirement to 1.26 if that's okay. That would be really appreciated. Otherwise, it would also work if you pop out a message saying this version of Engine API is not officially supported, many things may not work and to make it clear any tickets raised against this setup will not be accepted. That would be fair I guess. An official override - config settings or environment variable to make this check permissive would work here as well.
I totally understand the reason behind encouraging people to always upgrade the tools to the latest stable versions, but in our case - OpenShift 3.11 is in fact the latest stable version of the 3.x branch and switching from 3.x to 4.x isn't trivial so it will take us months to get there. Meanwhile we could enjoy using this fantastic tool, which from my experience boosts up the productivity a lot.
I will really appreciate your help here.

Thanks in advance!

Kind regards,
Waldek

[chrmarti]

https://github.com/microsoft/vscode-remote-release/issues/2334 showed that we need API version 1.35 or later to run. Is your implementation somehow supporting -w for docker exec?

[wherka]

Hi @chrmarti ,
the -w is not supported there indeed, but the implication is just a bit of an inconvenience. There are some oddities around the extensions and some other settings as they are not properly watched as you may be hinting on.

[2292 ms] Stop (10 ms): Run in container: cat /home/amadeus/.vscode-server-insiders/bin/24b28f57be22fe3029cb17a1dd72d8d9c2d6468b/.devport 2>/dev/null [2296 ms] Forwarding local port 33958 to container port 33958 [2324 ms] Start: Run: c:\Program Files\docker\docker-windows-amd64.exe exec -i -u amadeus -w /home/amadeus/.vscode-server-insiders/extensions 28078750d3b15a31159253fe86f20545b69c2e0878d74d5db9d73523f2323ff4 /bin/sh -c # Watch installed extensions [2326 ms] Start: Run: c:\Program Files\docker\docker-windows-amd64.exe exec -i -u amadeus -w /home/amadeus/.vscode-server-insiders/data/Machine 28078750d3b15a31159253fe86f20545b69c2e0878d74d5db9d73523f2323ff4 /bin/sh -c # Watch machine settings [2353 ms] Stop (2335 ms): Resolving remote [2476 ms] Start: Run: c:\Program Files\docker\docker-windows-amd64.exe exec -i -u amadeus -e VSCODE_REMOTE_CONTAINERS_SESSION=f5a46210-5705-44eb-9aa9-527d8343e63b1604956768520 28078750d3b15a31159253fe86f20545b69c2e0878d74d5db9d73523f2323ff4 /home/amadeus/.vscode-server-insiders/bin/24b28f57be22fe3029cb17a1dd72d8d9c2d6468b/node -e [2494 ms] Start: Run: c:\Program Files\docker\docker-windows-amd64.exe exec -i -u amadeus -e VSCODE_REMOTE_CONTAINERS_SESSION=f5a46210-5705-44eb-9aa9-527d8343e63b1604956768520 28078750d3b15a31159253fe86f20545b69c2e0878d74d5db9d73523f2323ff4 /home/amadeus/.vscode-server-insiders/bin/24b28f57be22fe3029cb17a1dd72d8d9c2d6468b/node -e [2633 ms] Stop (309 ms): Run: c:\Program Files\docker\docker-windows-amd64.exe exec -i -u amadeus -w /home/amadeus/.vscode-server-insiders/extensions 28078750d3b15a31159253fe86f20545b69c2e0878d74d5db9d73523f2323ff4 /bin/sh -c # Watch installed extensions [2634 ms] Start: Run: c:\Program Files\docker\docker-windows-amd64.exe exec -i -u amadeus -e VSCODE_AGENT_FOLDER=/home/amadeus/.vscode-server-insiders -w /home/amadeus/.vscode-server-insiders/bin/24b28f57be22fe3029cb17a1dd72d8d9c2d6468b 28078750d3b15a31159253fe86f20545b69c2e0878d74d5db9d73523f2323ff4 /home/amadeus/.vscode-server-insiders/bin/24b28f57be22fe3029cb17a1dd72d8d9c2d6468b/server.sh --disable-telemetry --list-extensions [2651 ms] Stop (325 ms): Run: c:\Program Files\docker\docker-windows-amd64.exe exec -i -u amadeus -w /home/amadeus/.vscode-server-insiders/data/Machine 28078750d3b15a31159253fe86f20545b69c2e0878d74d5db9d73523f2323ff4 /bin/sh -c # Watch machine settings [2652 ms] Start: Run in container: cat /home/amadeus/.vscode-server-insiders/data/Machine/settings.json [2657 ms] [2658 ms] cat: /home/amadeus/.vscode-server-insiders/data/Machine/settings.json: No such file or directory [2658 ms] Exit code 1 [2658 ms] Stop (6 ms): Run in container: cat /home/amadeus/.vscode-server-insiders/data/Machine/settings.json [2894 ms] Stop (260 ms): Run: c:\Program Files\docker\docker-windows-amd64.exe exec -i -u amadeus -e VSCODE_AGENT_FOLDER=/home/amadeus/.vscode-server-insiders -w /home/amadeus/.vscode-server-insiders/bin/24b28f57be22fe3029cb17a1dd72d8d9c2d6468b 28078750d3b15a31159253fe86f20545b69c2e0878d74d5db9d73523f2323ff4 /home/amadeus/.vscode-server-insiders/bin/24b28f57be22fe3029cb17a1dd72d8d9c2d6468b/server.sh --disable-telemetry --list-extensions [2894 ms] [2894 ms] "--workdir" requires API version 1.35, but the Docker daemon API version is 1.26

However, that's still a very usable platform to me compared to the alternatives we have right now. Therefore I would really appreciate if we can find a common ground here, so I'm not even asking for making the 1.26 as a mainstream minimal level. I would much rather keep the default behaviour i.e. prompting the users to upgrade their docker installation whenever it's possible, but allow to tweak the settings to get it passed to use the VSCode in somewhat degraded mode. To be honest it's merely a matter of installing the extensions, reloading the window and from then on it's business as usual - everything works just fine. I'm sure there are some scenarios where it may bisbehave, but I'm happy to accept these and promise not to bother you with any ticket if I'm using anything below the recommended API version.

[chrmarti]

I'm hesitant to add a workaround for something we don't support. Have you tried setting the Docker CLI path setting to a script that returns a specific version for docker version --format {{.Server.APIVersion}} and forward everything else to the original?

[wherka]

As far as I'm personally concerned this is not a big problem. I can rebuild my docker client to return a fake version. However, this is a bit bigger than this. We are talking about people who are stuck with OpenShift 3.x and who would potentially like to use VSCode on such hosts. There will be a large group of developers in my organisation in coming months who falls into this category.
I'm not so keen on advising each individual to rebuild their docker client as not everybody is so keen on tinkering with this process. I will publish such binaries internally only if there is no other choice. IMHO an extra line in the config and/or and extra environment variable would be much easier to swallow.
I believe the dependency on --workdir/-w could be mitigated as well, but since I have not really done any validation here I cannot tell for sure. It would be a lot easier if this extension was open sourced. Any chance I could perhaps join the contributors - at least temporarily and work on a fix in this area?

[chrmarti]

I'm adding an 'Ignore' button to the version check dialog, so you're unblocked. I'm not sure if -w for exec is the only thing missing from API version 1.26.

There is a FAQ on the license. I don't think there is a process for outside contributions.

[wherka]

Fantastic! You made my day @chrmarti
Thanks a lot!

BTW: I backported the --workdir/-w to the RHEL fork of the docker daemon which is used on my installation to compare the bahaviour to the current one that does not support it. As expected the whole thing went smoothly, no errors in the console and the watchers correctly started. So, that's a proper workaround on my end if I really have to go for it. However, with or without --workdir on exec VSCode makes an amazing difference to developers I'm looking after. A small inconvenience of reloading the window is a small price to pay indeed.
Thanks again for your understanding and support! Much appreciated.