Workaround for "Failed to update dependencies"

[amsoedal]

Issue 1: Maximum number of retries exceeded

Some of the time, getting dependencies for Bridge to Kubernetes in VS Code may fail with this error.

If the issue reproduces consistently after hitting the retry button, a manual workaround is the best way to proceed.

The workaround

1. Visit one of the below links in a browser (choose based on your platform):
   https://bridgetokubernetes.blob.core.windows.net/zip/lks/lpk-win.zip
   https://bridgetokubernetes.blob.core.windows.net/zip/lks/lpk-osx.zip
   https://bridgetokubernetes.blob.core.windows.net/zip/lks/lpk-linux.zip
   This will prompt the download of a .zip file.
2. Unzip the file and move the contents to the Visual Studio Code extension storage folder. You may need to create the directory if it does not exist.
   On Windows: %UserProfile%\AppData\Roaming\Code\User\globalStorage\mindaro.mindaro\file-downloader-downloads\binaries
   On MacOS: "/Users/your_username/Library/Application Support/Code/User/globalStorage/mindaro.mindaro/file-downloader-downloads/binaries"
   On Linux: /home/your_username/.config/Code/User/globalStorage/mindaro.mindaro/file-downloader-downloads/binaries
3. To check that the hierarchy is correct, you should now see folders called "kubectl" and "EndpointManager" along with several other files side-by-side under the /binaries/ directory.
4. IMPORTANT: If you are on Linux or Mac, you need to run: sudo chmod +x on dsc, kubectl/your_platform/kubectl and EndpointManager/EndpointManager.
5. Open VS Code again. The extension should now be able to find and execute its dependencies.

Long-term
We are currently at work trying to understand why this error happens and to improve the experience! Thank you for your patience.

Issue 2: EACCESS error

If you are on Linux, you might run into this issue:

The workaround

1. From a terminal, navigate to /home/your_username/.config/Code/User/globalStorage/mindaro.mindaro/file-downloader-downloads/binaries
2. Run: sudo chmod +x on dsc, kubectl/linux/kubectl and EndpointManager/EndpointManager.
3. Open VS Code again. The extension should now be able to find and execute its dependencies.

Long-term
This issue will be fixed in our next release -- stay tuned.

[sammym1982]

I have another flavor of same error . But these workaround does not seems to work :(

[daniv-msft]

@sammym1982 Thank you for reporting this, and sorry you have this issue. Could you please try to terminate the EndpointManager process manually (if you're on Windows, you should see this right in the Task Manager) and restart VS Code?
This is the process we start with elevated permissions when using Bridge to Kubernetes. We have some logic to automatically kill it when updating dependencies, but it seems that this logic didn't work as expected in your case.

[sammym1982]

Yes that was it. Thanks. One other thing to note when this process was running one of the logs file kept growing and in my case went upto almost 500GB which made my c drive go out of space.

[daniv-msft]

Thanks for your reply. Do you remember which log file it was? This is not something we caught earlier, and is very worrying so any help to track this would be appreciated.

[SVronskiy]

Got problem:

Failed to update dependencies: EPERM: operation not permitted, rename 'c:\Users\svron\AppData\Roaming\Code\User\globalStorage\mindaro.mindaro\file-downloader-downloads\ad5081f1-aa9e-4add-a9ad-3f768504a8f7' -> 'c:\Users\svron\AppData\Roaming\Code\User\globalStorage\mindaro.mindaro\file-downloader-downloads\binaries'
Source: Bridge to Kubernetes

There is no EndpointManager process in the Task Manager.
Manually renamed folder 'ad5081f1-aa9e-4add-a9ad-3f768504a8f7' to 'binaries' and this resolved my problem.

[daniv-msft]

Thanks @SVronskiy! We're aware of this issue and are investigating it, but we don't have a good solution yet. This might be a race condition where we try to rename the folder after downloading whereas a handle is still kept on it.
Adding @rakeshvanga for FYI.

[greenie-msft]

Hi everyone,

We have updated our code to be more resilient when downloading dependencies. Please let us know if you are still experiencing this issue. Keeping this thread open for now.

Thank you

[chudytom]

It still doesn't work for me when trying to run Kubernetes Bridge. It doesn't work on Windows nor in WSL. And the error I'm getting is
"Failed to update dependencies: Maximum number of retries exceeded. The operation 'HttpRequestHandler.get' failed with error: unable to get issuer certificate. Technical details: {"message":"unable to get issuer certificate","name":"Error","stack":"Error: unable to get issuer certificate\n\tat TLSSocket.onConnectSecure (_tls_wrap.js:1497:34)\n\tat TLSSocket.emit (events.js:315:20)\n\tat TLSSocket._finishInit (_tls_wrap.js:932:8)\n\tat TLSWrap.ssl.onhandshakedone (_tls_wrap.js:706:12)","config":{"url":"https://bridgetokubernetes.azureedge.net/zip/20210517.1/lpk-linux.zip","method":"get","headers":{"Accept":"application/json, text/plain, /","User-Agent":"axios/0.21.1"},"proxy":false,"transformRequest":[null],"transformResponse":[null],"timeout":5000,"responseType":"stream","xsrfCookieName":"XSRF-TOKEN","xsrfHeaderName":"X-XSRF-TOKEN","maxContentLength":-1,"maxBodyLength":-1},"code":"UNABLE_TO_GET_ISSUER_CERT"}"

[pragyamehta]

Hi @chudytom It seems you are unable to connect to our storage account where we host our binaries. Do you have any network policies that would prevent you from downloading our bits?
To get unblocked, you can try downloading our binaries manually from https://bridgetokubernetes.azureedge.net/zip/20210517.1/lpk-linux.zip

Once you download, you can unzip them and set the environment variable BRIDGE_BUILD_PATH to the binaries. Please let me know if this unblocks you. Thanks!

[chudytom]

Hi @pragyamehta Thanks a lot for the promtp response.

I tested the solution you proposed, downloaded the binaries manually put them in $HOME/bin/lpk-linux and set this location as BRIDGE_BUILD_PATH env var.
The workaround worked very nicely. Thank you very much for your help 😄
Before I tried to install the binaries manually on Windows and it didn't work. Is there a way to have it running on Windows as some developers on our side don't use WSL? Maybe we're able to ublock something specific in our firewal as indeed I am running behind corporate network policies. I tried to investigate what gets blocked specifically but still can't resolve it.
What FQDN does the extension use under the hood to download the binaries?
What is the location of the binaries after they are downloaded? (Windows)
Do you have some other ideas how to investigate it?

[rafeeqg]

Hi,
Can someone help with this please? I've tried to uninstall/re-install but nothing seems to be working. I am using VSCode on a Windows 10 host

Thanks!

[amsoedal]

Hi @rafeeqg, thanks for reporting this issue. To get unblocked, did you try the steps from the first issue (downloading from the link and putting the dependencies in the folder)? Hopefully it will get you unblocked as we try to understand the root cause for the 407 issue.