-
Notifications
You must be signed in to change notification settings - Fork 304
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
Release planning for 6.1.0 #767
Comments
Merged
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
github-project-automation
bot
moved this to Needs Shaping / Refinement
in DEPRECATED Engineering and Product Backlog
Sep 20, 2023
This was referenced Sep 22, 2023
damianavila
moved this from Needs Shaping / Refinement
to In progress
in DEPRECATED Engineering and Product Backlog
Sep 25, 2023
github-project-automation
bot
moved this from In progress
to Complete
in DEPRECATED Engineering and Product Backlog
Sep 28, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
KubeSpawner would benefit greatly from a release with #742 in it, what I think was a regression from previous major versions of KubeSpawner. Z2JH 3.0.0 - 3.0.3 users are affected by it. The consequences of this bug is that user pods can be left running in k8s while JupyterHub thinks the servers are stopped, and this can incurr significant cloud costs. Users with a stranded server can still re-start it via JupyterHub though.
To make this release, we should also include notes on how users can cleanup such stranded servers intelligently. @minrk has made a script that inspects k8s resources and the jupyterhub state to help figure out what user servers should be considered for cleanup.
Todo
profile_options
whenprofile_list
has entries named likeshort
andshort-plus
#702, fixed by Fix for unlisted_choice, docstring updates, and misc refactoring #773kubespawner_override
#785Todo related to
unlisted_choice
unlisted_choice
a second time has no effect #772Todo considered outside the scope of this release
The text was updated successfully, but these errors were encountered: