Can install one extension from marketplace but not others

[Jose-Matsuda]

Hello!
We're trying to leverage code-marketplace so that users can install vetted extensions in our locked down environment but are running into an issue when testing installing extensions from the deployed code-marketplace pod. As the title states, we are oddly able to install vim but nothing else

Setup

Code-Marketplace

Deployed code-marketplace in our internal k8s cluster using the helm chart.
For the ingress and TLS, our cluster uses Istio to handle that and as such is secured by mTLS, so in the deployed chart there is no tls block in the Ingress CRD.
Additionally, to minimize variables we have added the extensions to code-marketplace using by modifying the code-marketplace dockerfile to

    wget https://github.com/VSCodeVim/Vim/releases/download/v1.27.3/vim-1.27.3.vsix && \
    /opt/code-marketplace add vim-1.27.3.vsix --extensions-dir /extensions

Code-server leveraging code-marketplace

We have code-server v4.17.0 running in a jupyter notebook and have the environment variable of EXTENSIONS_GALLERY set to that https ingress host.

Network Policies + PeerAuthentication

Just for testing, I have tried adding blanket allow-all ingress and egress network policies on all the related namespaces; which would be the namespaces that have the code-server deployment, the code-marketplace service, as well as our namespace that has the Istio gateways as that's how the request is routed when we use the Ingress.
We have also added PeerAuthentication to the code-marketplace to allow the mTLS traffic.

Behaviour

Similar to #39, we are able to view the extensions that exist on our code-marketplace deployment, and see the extension's URL

And weirdly enough, we are able to install the vim extension, but only vim
The output log gives

2024-08-13 09:28:51.548 [info] Getting Manifest... vscodevim.vim
2024-08-13 09:28:51.589 [info] Installing extension: vscodevim.vim
2024-08-13 09:28:52.058 [warning] Error while fetching extension resources list JSON.parse: unexpected character at line 1 column 1 of the JSON data
2024-08-13 09:28:52.212 [info] Extension installed successfully: vscodevim.vim
2024-08-13 09:29:16.938 [info] Uninstalling extension from the profile: vscodevim.vim@1.27.3 vscode-remote:/home/jovyan/.local/share/code-server/User/extensions.json
2024-08-13 09:29:17.081 [info] Successfully uninstalled extension from the profile vscodevim.vim@1.27.3 vscode-remote:/home/jovyan/.local/share/code-server/User/extensions.json

Whereas attempting to install anything else gives

2024-08-13 09:29:25.870 [error] Error: read ECONNRESET
    at TLSWrap.onStreamRead (node:internal/stream_base_commons:217:20)
2024-08-13 09:29:25.872 [error] read ECONNRESET: Error: read ECONNRESET
    at TLSWrap.onStreamRead (node:internal/stream_base_commons:217:20)

and the "attempt to download manually" page of https://....ca/api/publishers/ms-toolsai/vsextensions/jupyter/2024.4.0/vspackage leads to a 404 Not Found (vim also leads to 404 if url is changed)

When I exec into the code-marketplace pod I can see all the extensions under /extensions.

Any insight would be greatly appreciated!

[code-asher]

The vim extension is a "web" extension (it downloads to and runs directly in the browser) while regular extensions download to the remote end. But as to why a download would work from the client machine and fail with ECONNRESET from the remote, I am not sure...are you able to curl the marketplace from the remote machine?

Maybe we have a bug with vspackage. Just to make sure, do you see the .vsix in the extension directory? /extensions/ms-toolsai/jupyter/2024.4.0/ms-toolsai.jupyter-2024.4.0.vsix is where it should be I think.

[code-asher]

Oh wait the vspackage path looks wrong. We have /publishers/ms-toolsai/vsextensions/jupyter/2024.4.0/vspackage but not /api/publishers/ms-toolsai/vsextensions/jupyter/2024.4.0/vspackage (no /api). Makes sense to me since it is a file download and not necessarily an API request, but I need to see if this is our fault or if this path comes from VS Code, in which case we will have no choice but to move the endpoint.

[code-asher]

Ah yup unfortunately the path is generated like this by VS Code, I will push up a fix for this in a moment.

[code-asher]

v2.2.1 is live with the vspackage fix.

[Jose-Matsuda]

Thank you for the quick response @code-asher !
So your fix does work for the attempt to download manually does work but my initial problem does persist.

I can't install from the Extensions Tab and when I do try to download manually, at least from the terminal I get;

(base) jovyan@novol-das-marketplace-0:~/workspace$ curl https://chart-example.ca/api/publishers/ms-toolsai/vsextensions/jupyter/2024.4.0/vspackage
curl: (35) Recv failure: Connection reset by peer

(base) jovyan@novol-das-marketplace-0:~/workspace$ wget https://chart-example.ca/api/publishers/ms-toolsai/vsextensions/jupyter/2024.4.0/vspackage
--2024-08-15 14:45:15--  https://chart-example.ca/api/publishers/ms-toolsai/vsextensions/jupyter/2024.4.0/vspackage
Resolving chart-example.ca (chart-example..ca)... .132
Connecting to chart-example.ca (chart-example.ca)|.132|:443... connected.
Unable to establish SSL connection.

Note that of course (as the network flows between the remote machine / code-marketplace are opened and all same cluster), using just the local cluster service url of wget test-code-marketplace.code-marketplace.svc.cluster.local/api/publishers/ms-toolsai/vsextensions/jupyter/2024.4.0/vspackage does work, but of course that then uses http and can't be used.

Again thank you for your help.

[code-asher]

Thank you for confirming the download link is fixed!

Hmm yeah that is strange. I have never configured Istio before so unfortunately I am not really sure what could be going wrong.

[Jose-Matsuda]

Ok that's all good thank you for your help thus far! We opened the issue just in case there was some obvious misconfiguration / misunderstanding on our part

[code-asher]

Completely understandable! I will close the issue since I think there is nothing to resolve in code-marketplace, since the http calls work.

If you happen to have a way to reproduce locally (maybe with minikube or something, I have not really messed much with Kubernetes though) I would be happy to at least try poking into it, maybe a set of fresh eyes will reveal something.

[code-asher]

You might also want to check with the Istio folks!