Download alternative server depending on platform requirements

[deepak1556]

As a next step in the linux server story we want to build and consume two different flavors of server that will be used depending on the platform requirements. This is useful to pretest the server with newer requirements before the EOL of legacy server which is currently set for February 2025.

1. Server with glibc >= 2.28 and libstdc++ >= 3.4.25
2. Server with glibc >= 2.17 and libstdc++ >= 3.4.19, we will call this legacy server

There are 3 parts to this next step,

(i) Production:

VS Code production pipeline will create the above two variants of the server for each of the linux supported architectures (x64, armhf, arm64). A prototype was already created in #204139, I will polish the PR and prepare it for merge as next step. The end result will look like the following screenshot.

(ii) Detection:

Today we have detection of glibc and libstdc++ in two variations, one in the tunnel binary used in the exec server mode and the other as a shell script. The shell script can only perform the detection on a best effort basis due to various limitations but thanks for efforts from the community it works in most cases.

However I wonder if we should just have one variant of the detection as part of this effort, basically we rely on the tunnel binary to do the detection, add a new property to ExecEnvironment that will provide the glibc version and libstdc++ max version. Thoughts @connor4312 ?

Another question, can the remote extensions today use the execServer mode just for detection even if it is not for the other parts of the modal ? That is, get the result from execServer.env() and proceed to their usual server setup flow.

export interface ExecEnvironment {
		...
             /** provides the result of gnu_get_libc_version **/
             glibcVersion?: string
             /** provides the maximum version of the symbol found in the libstdc++.so.6 library **/
             glibcxxMaxVersion?: string
}

(iii) Consumption:

This needs change in the places where the server gets downloaded today, based on the result of detection we want to either download from https://update.code.visualstudio.com/commit:${commit}/${legacy ? 'legacy-' : ''}server-${build.id}${web ? '-web' : ''}/${quality}. The only difference in the download endpoint will be the legacy- prefix.

Let me know if this plan makes sense.

[connor4312]

I made a draft PR for the CLI side of this a bit ago #204194. Consumers of the exec server let it do the download, so they just request the version of the server they need and the CLI will determine the appropriate one for the platform -- including the glibc check with that PR. Consumers who are already using the CLI won't need to do any changes in that regard.

Another question, can the remote extensions today use the execServer mode just for detection even if it is not for the other parts of the modal ? That is, get the result from execServer.env() and proceed to their usual server setup flow.

We could add a new method that would just return the server the CLI thinks is appropriate for the platfom.

[aeschli]

However, I wonder if we should just have one variant of the detection as part of this effort,

But don't we still use the shell script to get a nicer error message when running a regular code-server on a legacy platform?

[deepak1556]

Yes we used to do that based on the custom exit code from the shell script in containers and wsl, but we have disabled the exit code till the new end of support period is reached. It does make sense to have a similar feedback from the execServer so that we can bring back the error dialogs after February 2025. How about the following ?

export interface ExecServer {
   /**
    * Detects the server variant that can be executed on the current platform.
    * @returns a valid download url if all requirements are satisfied, otherwise 
    * a status object that contains the custom exit codes related to the specific failure.
    */
   getServerDownloadURL?(): Thenable<{url: string | undefined; status: ProcessExit}>;
}

[chrmarti]

Would using the CLI for version checking necessarily involve an additional download or could the CLI in the non-legacy server (is the CLI already part of the server?) be used to do that? If the percentage of legacy systems is low, it might make more sense to optimize for the non-legacy case.

Codespaces today downloads the server ahead of time to optimize startup time. The code doing the download and later the startup is owned by us and runs standalone on a VM (i.e., there is no VS Code API available).

[deepak1556]

After some offline discussion with @chrmarti , his main concerns were around startup performance and the codespaces scenario. Since the CLI is part of the server bundle which makes detection and download a two step process which we don't want to happen for the majority cases, what does everyone think of the following steps

1. Make non-legacy server the default
2. Use the bundled cli to do the detection, this will happen in the places were shell script is used today referenced in Download alternative server depending on platform requirements #206790 (comment)
3. If detection succeeds, continue with current server
4. If detection fails, download legacy server and proceed to connect

For codespaces, will keep the current legacy server as default and avoid any double downloads. There is an idea of caching both legacy and non-legacy servers but that is something to discuss as next step once we have finished transitioning the extensions.