-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TypeError: '<' not supported between instances of 'datetime.datetime' and 'float' #33
Comments
Need more details, such as the full Python traceback and where you are seeing this. One cause for this error used to be use of bad version of Tornado. Another is bad version of Python REST API client which would fail with newer Kubernetes versions. The details you provided isn't enough to know where or what is causing it. |
I encountered same error. Following is full error log in jupyterhub pod.
And this is a jupyterhub screen shot. |
Hi Any update on this error, i am getting the same error in openshift 4.5 |
I'm also having trouble with this problem. How can I deal with it? |
@JaimeMagiera @mosuke5 We are also facing this error in our OpenShift 4.6 cluster. Are you still having this problem? In the |
We are also facing this issue with OpenShift 4.6 Is this repository about JupyterHub still active? There has been no commit in more than a year More in general, it would be interesting to know more about where to find informations about deploying such a service on OpenShift. Because those services (like JupyterHub) are well documented and working on Kubernetes, but usually not documented and facing multiple deep permissions/implementations issues for RedHat OpenShift. According to @GrahamDumpleton in this post jupyter-on-openshift/jupyter-notebooks#27 the Note that:
For example, this documentation for JupyterHub deployment on kubernetes: https://zero-to-jupyterhub.readthedocs.io refers to the official JupyterHub Helm charts GitHub repo https://github.com/jupyterhub/helm-chart where the charts and templates are not available, and it is not clear where we can find them, so the charts cannot easily be tweaked to work OpenShift (not sure what is their motivation for hiding the Helm charts) It is surprising that the deployment JupyterHub, a quite common data science tool, is so convoluted and poorly documented on RedHat OpenShift, any idea where/how we can find a stable deployment for JupyterHub on OpenShift? |
No, these repositories are no longer being actively maintained. People from Red Hat are aware of this and understand it is a problem affecting a number of OpenShift users but although I am happy for them to take the repositories over I have not been approached to assign the repositories to them. The only officially supported solutions from Red Hat that I know of are still just opendatahub.io and radanalytics.io. |
Thanks @GrahamDumpleton for the feedback! This is quite concerning for everyone using RedHat products though The point of Kubernetes is to be able to deploy complex softwares on different systems (self hosted, GCP, AWS), with guarantee of stability. But with OpenShift, RedHat broke this major Kubernetes feature, and OpenShift users cannot re-use Kubernetes packages built by communities, they need to build from scratch the deployment for their OpenShift (which is more complex than kubernetes, and will lead to more security flaws) Additionally RedHat seems to be maintaining multiple version of JupyterHub/Jupyter: one for opendatahub and one for radanalytics. Wouldn't it possible to factorize efforts by using packaging systems properly? It seems to be much more efficient and logical to have 1 JupyterHub Helm chart working for OpenShift, and re-use this one Helm chart in OpenDataHub and radanalytics, instead of developing adhoc solution everytime. |
Hello, |
How do i fix this ? |
Using this on OpenShift 4.5, I'm getting the following:
TypeError: '<' not supported between instances of 'datetime.datetime' and 'float'
It's a quick fix, but wanted to give you a heads up in case you didn't see this.
The text was updated successfully, but these errors were encountered: