Avoiding client-server version mismatch and setting <quality>-<commit> programmatically

[iSuslov]

Hey guys, thank you for this awesome project!

I've been exploring the remote server functionality, and I have a question regarding version compatibility between the client and server, as mentioned in the "Production concerns" section:

The commit and product quality should be the same on the client and on the server to be able to connect them. It can be an issue if you have the server deployed on a cluster, and the client is upgraded progressively: it is required for the server to expose both old and new version.

It can be achieved because all calls to the server are prefixed by <quality>-<commit>. So both servers can be started on a different port, and a reverse proxy in front of them can redirect the calls based on the path prefix.

My questions:

1. Can you provide a concrete example of how to set up the reverse proxy to handle multiple versions? How error prone is to trick vscode-server with such reverse proxy?

2. Is it possible to programmatically set the <quality>-<commit> on the client side? So we don't need a reverse proxy.

3. Are there any best practices or recommended approaches for managing version compatibility in a production environment where client and server updates may not always be simultaneous?

Thank you for your time and for maintaining this project.

[CGNonofr]

Can you provide a concrete example of how to set up the reverse proxy to handle multiple versions?

If used with K8S, it's pretty straighforward

• Run the 2 server versions in your container in port 80 and 81 for instance
• Configure the service and ingress with path prefixes:

apiVersion: v1
kind: Service
metadata:
  name: vscode-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
    - protocol: TCP
      port: 81
      targetPort: 81
------
apiVersion: networking.k8s.io/v1
kind: Ingress
spec:
  rules:
    - host: example.net
      http:
        paths:
          - path: /stable-fee1edb8d6d72a0ddff41e5f71a671c23ed924b9
            pathType: Prefix
            backend:
              service:
                name: vscode-service
                port:
                  number: 80
          - path: /stable-eaa41d57266683296de7d118f574d0c2652e1fc4
            pathType: Prefix
            backend:
              service:
                name: vscode-service
                port:
                  number: 81

(not tested at all)

How error prone is to trick vscode-server with such reverse proxy?

I don't think it can be considered as tricking VSCode, I'm even convinced that that prefix exists exactly for that reason

Is it possible to programmatically set the <quality>-<commit> on the client side? So we don't need a reverse proxy.

It's possible: in the workbenchConstructOptions (the parameter of the initialize method) you can provide a productConfiguration which can be used to override the quality and the commit

It's probably ok for patch version, but you can't really be sure there is no incompatibility

Are there any best practices or recommended approaches for managing version compatibility in a production environment where client and server updates may not always be simultaneous?

I can imagine 3 approaches:

• Do as discussed:
  • Update your images to make sure they expose both the previous and current version of the server behind a properly configured reverse proxy
  • Then deploy the client update
• Keep 2 versions of your image in the backend, and chose which one to use based on the client VSCode version
• Make your container serve the VSCode front, either by deploying your app in your images (or a part or it, displayed inside an iframe) (or even using a real VSCode with something like https://github.com/coder/code-server it you don't need to customize it)

[iSuslov]

Thank you for such a detailed answer! When I try your suggestions I will definitely write an update in this discussion for future reference.