Unify Openscapes profile list config #3625
Conversation
|
I'll communicate to the community and find a good time for this. |
|
Merging this PR will trigger the following deployment actions. Support and Staging deployments
Production deployments
|
| do this at a time when minimal or no users are running, to minimze | ||
| disruption. | ||
|
|
||
| 2. We log everyone out by regenerating [hub.cookieSecret](https://z2jh.jupyter.org/en/stable/resources/reference.html#hub-cookiesecret). |
There was a problem hiding this comment.
Presuming I have the use case correct (there is a hub that was already using GitHub teams/org auth so already have a GitHub OAuth App, and now they want teams-based access to profiles) and there isn't anything more complicated happening at the hub-level, I actually think there is an easier way to do this that does not involve using kubectl at all:
- Go to the GitHub OAuth App settings page for the hub, e.g., Openscapes staging is here https://github.com/organizations/2i2c-org/settings/applications/2367936
- Click "Revoke all user tokens"
This will also force the oauth flow and make everyone login again.
We have this documented here as a method of debugging when someone did not correctly authorise the GitHub OAuth App on first login.
There was a problem hiding this comment.
@sgibson91 Thanks for pointing that out - I had not considered that! It would indeed be much simpler! However, I just tried that and it did not work :( I think it works for the 'Authorize' use case because they are not JupyterHub users yet at that point. In this case, since they've already been successfully authenticated into JupyterHub, revoking GitHub creds does nothing, since they're using JupyterHub cookies / creds at that point. It would only take effect after they explicitly log out of JupyterHub. So we need to rotate cookie secret instead.
|
Sorry, #3633 caused the conflict |
There was a problem hiding this comment.
For consistency could you add this kind of change from #3621 as part of adding profileList overriding the image, I figure it can't be used for the /lab /rstudio path either at this point anyhow right?
I'm a bit concerned seeing things standardize towards requests=limits on memory, which is something i suspect ends up compromising more on cloud costs and users per node/startup times more than the communities merits from.
Since we don't have a system to observe pod evictions (jupyterhub/grafana-dashboards#65) or be alerted if they happen, its less problematic to go for this very safe and easy-to-reason-about approach though.
|
@consideRatio I opened #3635 to tackle the configurator issue. |
The staging hub was separate only to make sure people can bring their own image. This PR merges that functionality in, and uses our team based profile access instead. Since this requires auth_state to be enabled, we actually need to *log out* everyone before deploying this. That can be done with `k -n <namespace> delete secret hub` manually before deployment. To minimize interruption, this should be co-ordinated with the openscapes community I've also added some documentation on how to enable this feature for communities with pre-existing users
yuvipanda
force-pushed
the
openscapes-unify
branch
from
8bff6db to
9c64733
Compare
|
🎉🎉🎉🎉 Monitor the deployment of the hubs here 👉 https://github.com/2i2c-org/infrastructure/actions/runs/7706775302 |
|
Resolved conflict, and merged as there weren't any real active users right now. I've reset the hub secret as well. |
The staging hub was separate only to make sure people can bring their own image. This PR merges that functionality in, and uses our team based profile access instead.
Since this requires auth_state to be enabled, we actually need to log out everyone before deploying this. That can be done with
k -n <namespace> delete secret hubmanually before deployment. To minimize interruption, this should be co-ordinated with the openscapes communityI've also added some documentation on how to enable this feature for communities with pre-existing users
📚 Documentation preview 📚: https://2i2c-pilot-hubs--3625.org.readthedocs.build/en/3625/