You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The user-scheduler deployment current has a desired size 2
spec:
replicas: 2
Only 1 user-scheduler pod can be active at a time.
1 user-scheduler pod acquires the leader-lock, and handles user requests for new hubs.
The other user-scheduler just waits.
I0723 23:54:51.705523 1 leaderelection.go:352] lock is held by user-scheduler-fc9c5b9bf-2chsl_184ca957-05ce-404b-867c-4ff2438352d4 and has not yet expired
I0723 23:54:51.705546 1 leaderelection.go:253] failed to acquire lease jupyterhub/user-scheduler-lock
This is a good pattern for highly available applications, but
I don't think the user-scheduler goes down frequently.
user-scheduelr doesnt take long to start up
the hub pod doesn't have a backup
So its not clear if this is offering any benefit at all.
The text was updated successfully, but these errors were encountered:
The user-scheduler deployment current has a desired size 2
Only 1 user-scheduler pod can be active at a time.
1 user-scheduler pod acquires the leader-lock, and handles user requests for new hubs.
The other user-scheduler just waits.
This is a good pattern for highly available applications, but
So its not clear if this is offering any benefit at all.
The text was updated successfully, but these errors were encountered: