Release planning for 6.1.0

[consideRatio]

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

• 702, fixed by #773

• 742

• 785

• 787

• 768

Todo related to unlisted_choice

• 758, fixed by #772

• 756, fixed by #778

• 757

Todo considered outside the scope of this release

• 775

[yuvipanda]

https://github.com/jupyterhub/kubespawner/issues/758 is definitely a blocker. I think https://github.com/jupyterhub/kubespawner/issues/702 should also be in this.

[consideRatio]

• 702 is fixed by #773

• I'd appreciate getting #774 into the release as well

[consideRatio]

@GeorgianaElena do you want to work on extracting out some logic from spawner.py before a release, or should we move ahead with 6.1.0?

[consideRatio]

Or anything else?

[GeorgianaElena]

@GeorgianaElena do you want to work on extracting out some logic from spawner.py before a release, or should we move ahead with 6.1.0?

Hmm, is the kubespawner release blocking other projecta? Right now I'm inclined to say that we should cut a realease first and not block on the refactor since we ca patch it later? At the same time, if we get a bug report about profiles, it would be amazing to have all the logic refactored into its own module and not have to fiddle around this big file.

Since I would only be able to tackle the refactor sometime early next week and I don't want to block the release on my availability, I will leave the final decision to you @consideRatio!

Thank you for pushing forward on this @consideRatio <3

[consideRatio]

No other project is blocked!

kubespawner (and z2jh where its mainly consumed) could benefit from having whats already merged in KubeSpawner released sooner rather than later though. The main branch currently includes a bugfix and a performance improvement besides the new unlisted_choice feature.

I opened #775 about refactoring work to extract profile_list related logic from spawner.py. Not feeling confident on how much work it will end up being, so it feels good to get this out first.

I've opened #768 and figure we'll release kubespawner 6.1.0 and z2jh 3.1.0 on monday if approved.

[consideRatio]

Change of mind, lets wait with 6.1.0!

@batpad is working on the unlisted_choice feature addressing #756 and #757. I don't want us to go for a 6.1.0 then but instead with a 6.1.0 release until the implementation of #756 is known. I think that implementation of #756 could benefit from the ease of making a breaking change in a not-yet-released feature. I don't know if breaking change is relevant for #756, but I don't rule it out.

[consideRatio]

• Waiting for #778, otherwise 6.1.0 can be release I think

[yuvipanda]

https://github.com/jupyterhub/kubespawner/pull/785 also blocks 6.1.0