The current method for creating a new workspace on JupyterHub involves creating a new AnalyticsWorkspace which is a custom resource definition defined here.
Between the two some of the common override options are dealt with but not every configuration option that is possible to override on KubeSpawner.
Ideally we want most, if not all, options available to override and the Python module needs to be able to apply these to the singleuser pod.
There are possibly 2 approaches (if not more) to doing this.
Option 1:
Simplify the existing CRD to simply take any Yaml under a kubespawner_override key.
Advantage: Avoids creating (and managing) a more extensive CRD that can handle everything that is applicable to KubeSpawner
Disadvantage: We lose the testing/validation that comes with CRD and will end up with difficult to debug errors that will surface to the end user as strange http errors.
Option 2:
Modify the existing CRD and python module to allow all settings available for Kubespawner.
Advantage: Robust validation and testing with better integration into our existing k8s architecture.
Disadvantage: Greater initial effort. The CRD has to be updated when/if Kubespawner brings breaking changes.
The current method for creating a new workspace on JupyterHub involves creating a new
AnalyticsWorkspacewhich is a custom resource definition defined here.This is then read by a python workspace management module.
Between the two some of the common override options are dealt with but not every configuration option that is possible to override on KubeSpawner.
Ideally we want most, if not all, options available to override and the Python module needs to be able to apply these to the singleuser pod.
There are possibly 2 approaches (if not more) to doing this.
Option 1:
Simplify the existing CRD to simply take any Yaml under a kubespawner_override key.
Advantage: Avoids creating (and managing) a more extensive CRD that can handle everything that is applicable to KubeSpawner
Disadvantage: We lose the testing/validation that comes with CRD and will end up with difficult to debug errors that will surface to the end user as strange http errors.
Option 2:
Modify the existing CRD and python module to allow all settings available for Kubespawner.
Advantage: Robust validation and testing with better integration into our existing k8s architecture.
Disadvantage: Greater initial effort. The CRD has to be updated when/if Kubespawner brings breaking changes.