Simon Li

``` FAILED tests/unit/test_r.py::test_version_specification[-4.2] - AssertionError: assert False + where False = ('4.2') + where = '4.4.2'.startswith + where '4.4.2' = .r_version ```

The morning meetings usually clash with something else, but I should be able to facilitate some of the afternoon meetings for the first hour assuming they change with daylight savings...

Done in https://github.com/manics/jupyter-offlinenotebook/pull/662 but needs to be tested

Thanks, I think having a full example makes sense. What do you think about linking to our test config instead: https://github.com/jupyterhub/jupyter-server-proxy/blob/main/tests/resources/jupyter_server_config.py The advantage of that is it's always tested so...

That's a fair point! Can you change your example so that it'll work on all systems? At the moment it'll only work with anaconda. For example, import and use `sys.executable`

https://github.com/kubernetes/kube-state-metrics/blob/b1c2e0c1cf897202fa10da7b622e883df8a7a66e/docs/metrics/workload/pod-metrics.md#useful-metrics-queries suggests `count(kube_pod_deletion_timestamp) by (namespace, pod) * count(kube_pod_status_reason{reason="NodeLost"} == 0) by (namespace, pod)`

It's very basic, it just checks a connection is possible: https://github.com/jupyterhub/binderhub/blob/a8a2e197d5ebbed78f1ee5ee3a40547dc8e0f7eb/binderhub/health.py#L150-L159 We could potentially have a more complex check, though it might end up being specific to the registry implementation

We're already calling a Registry class method in the health check - https://github.com/jupyterhub/binderhub/blob/a8a2e197d5ebbed78f1ee5ee3a40547dc8e0f7eb/binderhub/health.py#L158C24-L158C42 - https://github.com/jupyterhub/binderhub/blob/c71bd8af339c08d9d673a369fe83225cb672d7b3/binderhub/registry.py#L272 so I think it'd be fine to add a new `health_check` method to the registry...

As it happens overriding the PVC template in `kubespawner_overrides won't work at the moment: - https://github.com/jupyterhub/kubespawner/issues/761 - https://github.com/jupyterhub/kubespawner/pull/820 so the only way to run into this bug is if `KubeSpawner.pvc_name_template`...

If you're running multiple containers in JupyterHub you're already using a fairly advanced low-level configuration since `extra_containers` requires writing something close to raw Kubernetes manifests, and `extra_pod_config` avoids adding more...