I am using GKE for Jupyterhub deployment. I followed the step given in Documentation but I am facing kernel connection issue.
I am using Helm Chart version 1.2.
Jupyterhub version 1.5
I saw a similar issue posted here: https://github.com/jupyter/notebook/issues/2664, I changed the tornado version but issue still persist.
In the console when I checked It was showing Websocket connection Failure
Seeing error below :
"upstream connect error or disconnect/reset before headers. reset reason: connection failure" when tried with below steps:
have created AKS cluster and deployed ASP.NET core docker container. Have installed Istio as per instructions below:
https://learn.microsoft.com/en-us/azure/aks/servicemesh-istio-install?pivots=client-operating-system-windows
Have deployed ASP.NET core docker container in default namespace with istio-injection enabled. Here below is the virtual service and gateway yaml files.
After all this when trying to access http://52.224.26.59/Home/View where 52.224.26.59 is external ip of istio-ingressgateway getting error as "upstream connect error or disconnect/reset before headers. reset reason: connection failure".
I have resolved this issue.
It's because of an issue with an older version of .NET Core version.
Once I updated with .NET Core 3.1, I was able to deploy and access .NET Core WebAPI.
Regarding other issues, there are more challenges and road is not clear with Istio and .NET core combination.
I'am running Istio 1.3.5 on my kubernetes cluster. I have installed it using Helm. But, this method will be deprecated in the future, so I'd like to migrate to Istioctl.
Is there a way to migrate "silently" my actual Istio deployment from helm to istioctl ?
I read something about istioctl manifest migrate but it's not very clear.
I also read that I need to upgrade to 1.4.3 before upgrading to 1.5.x. So I'd like to take this opportunity to switch to the Istioctl installation mode.
Thank you for your help.
Unfortunately there is not yet a migration path for helm to istioctl.
There is an issue on github exactly about that.
There is not yet a migration path for helm to istioctl, but it will certainly exist in 1.6,which is what this issue is tracking. You can go directly from 1.4 - 1.6 if desired once that is in place. Sorry about some of the confusion, as didn't do a great job around this
So waiting a little bit more might be the easiest solution. As with migration path will most likely offer better support and documentation.
Like You mentioned it is possible to manually migrate istio from helm to istioctl after upgrading with helm first. However this is not a simple task.
Hope it helps.
Unable to deploy my app as I started getting below error since today morning.
I have tried gcloud info --run-diagnostics and gcloud components reinstall without much help.
I tried to deploy it using the old Google App Engine Launcher for Windows but faced the same error.
Earlier it worked till yesterday night (IST) using gcloud. Please help!
I am on latest gcloud sdk and have updated all its components. I use Win10. I tried rebooting my laptop as well.
C:\gaurav\coding\python\myapp\myapp\dist>gcloud app deploy --project=myproject --version 1 --verbosity=info ./app.yaml
INFO: Refreshing access_token
ERROR: gcloud crashed (SSLHandshakeError): [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661)
If you would like to report this issue, please run the following command:
gcloud feedback
To check gcloud for common problems, please run the following command:
gcloud info --run-diagnostics
C:\gaurav\coding\python\myapp\myapp\dist>
Diagnostics Output.
C:\gaurav\coding\python\myapp\myapp\dist> gcloud info --run-diagnostics
Network diagnostic detects and fixes local network connection issues.
Checking network connection...done.
ERROR: Reachability Check failed.
Cannot reach https://accounts.google.com (SSLHandshakeError)
Cannot reach https://cloudresourcemanager.googleapis.com/v1beta1/projects (SSLHandshakeError)
Cannot reach https://www.googleapis.com/auth/cloud-platform (SSLHandshakeError)
Network connection problems may be due to proxy or firewall settings.
Do you have a network proxy you would like to set in gcloud (Y/n)? n
ERROR: Network diagnostic (0/1 checks) failed.
C:\gaurav\coding\python\myapp\myapp\dist>
Although gcloud info --run-diagnostics complains that the three URLs are not reachable. I am able to open them from web browser.
I found that when using Fiddler (for viewing network traffic) and have decrypting https traffic enabled, then I received the SSLHandshakeError.
Stopping the tool (or choosing not to decrypt https traffic) and then running the gcloud resulted in success.
According to the comments, also a problem with other web debugging proxies such as Charles.
A problem in recent GAE and GCloud SDK versions is the presence of invalid SSH certificates, see, for example, Google App Engine SSL Certificate Error and issue 38338974.
You could try to use my suggested solution in the above-mentioned post and replace your SDK's certificate file with a valid one (will have to locate a good one for the gcloud SDK, my answer was for the GAE SDK).
You might also be able to use the gcloud config command to set the core custom_ca_certs_file configurable property to point to a file with up to date certificates, if you have one. I didn't try it, YMMV.
Upgrading to Python 2.7.9 on MacOS High Sierra solved the issue for me.
I had this issue upon install of the google cloud SDK on MacOS Mojave. I am not behind a corporate proxy, and all the answers on the web seemed to indicate that this was the issue. I noticed in the install.sh script that it takes an environment variable CLOUDSDK_PYTHON for the python executable. So, I fixed this by exporting the path to my python 3 executable.
In my case:
export CLOUDSDK_PYTHON=/Library/Frameworks/Python.framework/Versions/3.6/bin/python3.6
The install worked as expected after this.
On MacOS Catalina, the solution was to completely uninstall gcloud and reinstall it.
I had the same issue, downloaded the root/intermediate cert from one of the google url you get when you run the command: gcloud info --run-diagnostics and append to the cacerts.txt file that is being used. In my case it was the following one: google-cloud-sdk/lib/third_party/httplib2/python2/httplib2/cacerts.txt
For me it was a conflict in the python versions. gcloud was calling a different version. The solution was to set CLOUDSDK_PYTHON to point to the correct python (python2 in this case).
I tried to deploy gcloud and I was getting this error. Here is how I fixed it:
Access to Google cloud using Firefox
Download certificate. pem file and chain file
Append them on cert.pem located at:
C:\Program Files\google-cloud-sdk\lib\third_party\certifi\cert.pem
(using this you are creating custom CA cert file based on your proxy)
Update cert file as mentioned here: https://cloud.google.com/sdk/gcloud/reference/config/set
(Absolute path to a custom CA cert file.)
Make sure you have cert.pem at the end of path.
I fixed the problem by installing gcloud from apt-get. The guide is at this link
I'm working on a project that I haven't touched in about 4 months. Before everything on the deploy was working fine, but now I'm getting an error when trying to deploy an update.
Failed to pull Docker image amazon/aws-eb-python:3.4.2-onbuild-3.5.1: Pulling repository amazon/aws-eb-python time="2016-01-17T01:40:45Z" level="fatal" msg="Could not reach any registry endpoint" . Check snapshot logs for details. Hook /opt/elasticbeanstalk/hooks/appdeploy/pre/03build.sh failed. For more detail, check /var/log/eb-activity.log using console or EB CLI.
In the eb-activity log, it further states [CMD-AppDeploy/AppDeployStage0/AppDeployPreHook/03build.sh] : Activity execution failed, because: Pulling repository amazon/aws-eb-python before repeating what was shown in the UI.
The original was using a Preconfigured Docker 64bit Debian jessie v1.3.1 running Python 3.4. I've tried upgrading to the latest, which is version 2.0.6, but it never completes (don't need to get into specifics of that error, separate issue and I'd like to stay on 1.3.1 if possible). I've also tried upgrading to the latest 1.x but it has the same result of upgrading to 2.0.6.
Any ideas, or anything else I should be looking for clues?
Docker Hub has deprecated pulls from Docker clients on 1.5 and earlier. Make sure that your docker client version is at least above 1.5. See https://blog.docker.com/2015/10/docker-hub-deprecation-1-5/ for more information.