No attribute `_start_future`
See original GitHub issueKubeSpawner
object has no attribute _start_future
I get this error in my hub log from time to time. Note that the users will be redirected instantaneously to the progress page, which is a new thing.
This does not affect my deployment as far as I know, only the logs, which causes some raised eyebrows.
[W 2018-09-18 17:48:06.542 JupyterHub base:714] User erik.sundell is slow to start (timeout=0)
[I 2018-09-18 17:48:06.544 JupyterHub base:1056] erik.sundell is pending spawn
[I 2018-09-18 17:48:06.548 JupyterHub log:158] 200 GET /hub/user/erik.sundell/ (erik.sundell@xxx.xxx.xxx.xxx) 81.35ms
[E 2018-09-18 17:48:06.826 JupyterHub web:1670] Uncaught exception GET /hub/api/users/erik.sundell/server/progress (10.132.0.14)
HTTPServerRequest(protocol='https', host='hub.example.com', method='GET', uri='/hub/api/users/erik.sundell/server/progress', version='HTTP/1.1', remote_ip='10.132.0.14')
Traceback (most recent call last):
File "/usr/local/lib/python3.6/dist-packages/tornado/web.py", line 1592, in _execute
result = yield result
File "/usr/local/lib/python3.6/dist-packages/jupyterhub/apihandlers/users.py", line 496, in get
async for event in events:
File "/usr/local/lib/python3.6/dist-packages/async_generator/_impl.py", line 366, in step
return await ANextIter(self._it, start_fn, *args)
File "/usr/local/lib/python3.6/dist-packages/async_generator/_impl.py", line 199, in __next__
return self._invoke(self._it.__next__)
File "/usr/local/lib/python3.6/dist-packages/async_generator/_impl.py", line 209, in _invoke
result = fn(*args)
File "/usr/local/lib/python3.6/dist-packages/jupyterhub/utils.py", line 495, in iterate_until
await yield_(item_future.result())
File "/usr/local/lib/python3.6/dist-packages/async_generator/_impl.py", line 366, in step
return await ANextIter(self._it, start_fn, *args)
File "/usr/local/lib/python3.6/dist-packages/async_generator/_impl.py", line 197, in __next__
return self._invoke(first_fn, *first_args)
File "/usr/local/lib/python3.6/dist-packages/async_generator/_impl.py", line 209, in _invoke
result = fn(*args)
File "/usr/local/lib/python3.6/dist-packages/jupyterhub/spawner.py", line 745, in _generate_progress
async for event in progress:
File "/usr/local/lib/python3.6/dist-packages/async_generator/_impl.py", line 366, in step
return await ANextIter(self._it, start_fn, *args)
File "/usr/local/lib/python3.6/dist-packages/async_generator/_impl.py", line 197, in __next__
return self._invoke(first_fn, *first_args)
File "/usr/local/lib/python3.6/dist-packages/async_generator/_impl.py", line 209, in _invoke
result = fn(*args)
File "/usr/local/lib/python3.6/dist-packages/kubespawner/spawner.py", line 1526, in progress
start_future = self._start_future
AttributeError: 'KubeSpawner' object has no attribute '_start_future'
[E 2018-09-18 17:48:06.827 JupyterHub web:1091] Cannot send error response after headers written
[I 2018-09-18 17:48:06.828 JupyterHub log:158] 200 GET /hub/api/users/erik.sundell/server/progress (erik.sundell@xxx.xxx.xxx.xxx) 126.98ms
[I 2018-09-18 17:48:06.833 JupyterHub spawner:1671] PVC claim-erik-2esundell already exists, so did not create new pvc.
[I 2018-09-18 17:48:27.785 JupyterHub log:158] 200 GET /hub/api (@xxx.xxx.xxx.xxx) 1.21ms
[I 2018-09-18 17:48:30.894 JupyterHub base:628] User erik.sundell took 24.408 seconds to start
[I 2018-09-18 17:48:30.895 JupyterHub proxy:242] Adding user erik.sundell to proxy /user/erik.sundell/ => http://xxx.xxx.xxx.xxx:8888
[I 2018-09-18 17:48:30.898 JupyterHub users:510] Server erik.sundell is ready
[I 2018-09-18 17:48:30.899 JupyterHub log:158] 200 GET /hub/api/users/erik.sundell/server/progress (erik.sundell@xxx.xxx.xxx.xxx) 21028.49ms
[I 2018-09-18 17:48:30.960 JupyterHub log:158] 302 GET /hub/user/erik.sundell/ -> /user/erik.sundell/?redirects=1 (erik.sundell@xxx.xxx.xxx.xxx) 12.06ms
[I 2018-09-18 17:48:31.113 JupyterHub log:158] 302 GET /hub/api/oauth2/authorize?client_id=jupyterhub-user-erik.sundell&redirect_uri=%2Fuser%2Ferik.sundell%2Foauth_callback&response_type=code&state=[secret] -> /user/erik.sundell/oauth_callback?code=[secret]&state=[secret] (erik.sundell@xxx.xxx.xxx.xxx) 28.16ms
@minrk wrote
This is interesting! It means the progress API is being called before start. I would think this is a bug in the timing of method calls, but it’s likely that
start
is “scheduled immediately” rather than kicked-off in a synchronous way that would ensure it’s actually called before progress. We should wait until_start_future
is defined in progress.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:1
- Comments:9 (7 by maintainers)
Top Results From Across the Web
DeploymentOptions setMaxWorkerExecuteTime · Issue #203
setMaxWorkerExecuteTime has any effect. Looking into the code I do not see that the method getMaxWorkerExecuteTime is invoked anywhere and I do ...
Read more >java - Vertx is not binding Routers
First, not everything in Vert.x is a lambda expression. That's just quite a weird tutorial you've found. As you can see, it uses...
Read more >Example usage for io.vertx.core.file FileSystem writeFile
fileSystem(); Future<Void> startFuture = Future.future(); Future<Void> fut1 ... log.trace("credentials registry does not need to be persisted"); return ...
Read more >How to Run a Vert.x Cluster With Broadcasting Messaging
We reviewed how to work with multiple verticles and communication in the previous article. In this article, I will attempt to explain how...
Read more >Futures and Promises
Futures provide a way to reason about performing many operations in parallel– in an efficient and non-blocking way. A Future is a placeholder...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
There is an open PR waiting to be merged that would resolve this: https://github.com/jupyterhub/kubespawner/pull/511
I never did, but internally we’re still not quite at current JupyterHub.