-
Notifications
You must be signed in to change notification settings - Fork 30
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
spawn failing after stopping and starting redis container #242
Comments
I think I know what's happening here. Since redis doesn't have persistent storage, the config create by I think the fix is to call |
Hi @minrk, I think I can see why that might cause new server routes not to work, but why the Redis |
The Redis client is initialised once: traefik-proxy/jupyterhub_traefik_proxy/redis.py Lines 28 to 55 in 9aafdc4
so maybe the connection is invalidated by the restart? |
@manics the asyncio Redis client uses a connection pool by default right? |
We should be using a default retry, which would fix the ConnectionError, I think. |
Thanks for the suggestion on trying Redis persistence - unfortunately it doesn't seem to change the behavior. I changed the service to:
in
|
There are two issues here:
|
This does not appear to address the issue. I added:
to |
The retry fix should work if you But the root problem seems to be on the traefik side, where we seem to be hitting traefik/traefik#6832 which was closed optimistically based on a dependency update, but without a confirmed fix. traefik/traefik#8749 (comment) suggests that we need to enable keyspace events in order for traefik watch to work properly. Why the issue only occurs after a disconnect rather than always? 🤷 Combining all that:
from redis.backoff import ExponentialBackoff
from redis.asyncio.retry import Retry
from redis.exceptions import (
BusyLoadingError,
ConnectionError,
TimeoutError
)
retry = Retry(ExponentialBackoff(), 3)
c.TraefikRedisProxy.redis_client_kwargs = dict(
retry=retry,
retry_on_error=[BusyLoadingError, ConnectionError, TimeoutError]
)
redis:
environment:
REDIS_ARGS: "--appendonly yes --notify-keyspace-events KEA" the problem seems to go away for me. |
#244 adds default retry config, while #246 documents the requirement for persistence and with those two everything seems to work for me. I opened #247 as a separate issue for the loss/restore of the initial dynamic config, which is part of why we currently have the implicit assumption of persistence. |
Thanks! The latest commit looks good on my end, both locally and with a k8s setup that we've got, so I'll close this out with those two PRs in. |
Thanks for reporting and testing! |
Bug description
I'm using a local Jupyterhub instance using using TraefikRedisProxy, where Jupyterhub, Traefik, and Redis each have their own container and all three containers are brought up with Docker Compose. After bringing everything up, if I stop and start the Redis container, a server fails to spawn.
How to reproduce
docker build -t jupyterhub-demo-redis .
docker-compose up redis traefik jupyterhub
docker-compose stop redis
docker-compose start redis
I've included the
Dockerfile
,docker-compose.yml
,jupyterhub_config.py
, andtraefik.toml
files in thefiles.tgz
archive attached:files.tgz
Expected behaviour
Redis should be able to stop and start without causing interference to spawning.
Actual behaviour
Stopping and starting Redis causes servers with new routes to fail to spawn.
Your personal set up
Jupyterhub container log:
jupyterhub.log
The text was updated successfully, but these errors were encountered: