Configurator for environment customization

[yuvipanda]

Description

There are a bunch of config changes that can be made by hub admins without risk of bringing their own hub down in an unrecoverable way. Currently, they need to be made via PR to this repo, involving time from 2i2c engineers. This slows down hub admins, and takes up 2i2c engineer time.

We should make these 'self serve' instead, where admins can use a familiar GUI to make changes themselves. This GUI should be devoid of footguns, where admins can accidentally delete everything and lock themselves out.

To begin with, the configuration GUI should allow admins to:

1. Change the default UI (Lab / RStudio / Notebook)
2. Change the default image. We should offer a pre-selected list of images as well as allow users to use anything custom
3. Modify RAM / CPU requests & limits. These should be done across a range set by 2i2c engineers, to make sure this doesn't go over our ability to pay.
4. An editor for profile lists, so admins can configure different options for users to choose from.

Inspired in part by tljh-repo2docker (via @jptio)

Benefit

As a hub administrator, I want to change some settings without involving 2i2c engineers so that it can happen more quickly and without hassle.

Implementation

We can iterate in the https://github.com/yuvipanda/jupyterhub-configurator repository. Here's a preview of how it looks currently:

I want to have something minimal deployed functionally before end of march, and hopefully we can have a complete deployment before start of next NA academic semester.

Tasks to complete

• Write up a small design document that lays out how the configurator should be built, keeping in mind needs of hub admins as well as 2i2c engineers. This will drastically affect this goal
• Setup all the scaffolding (frontend / backend build systems, hub API interaction, hub service interaction, etc)
• Build the interface picker, deploy it to production
• Build the image picker, deploy it to production
• Build RAM / CPU configurer, deploy it to production
• Build profile list editor, deploy it to production
• Automate building and pushing images for users with repo2docker action #630
• Documentation about the configurator in the Hub Adminsitrator's guide

[choldgraf]

Hey @yuvipanda - what's the status of this one? It seems like it much progress has been made in the configurator but not sure if these boxes should be checked or not :-)

[damianavila]

@yuvipanda quick question coming to my mind when I looked into this issue.
Maybe this is already solved by the configurator somehow, so feel free to point me to the specific code if that is the case!
I am wondering how do you reconcile the fact that after some admin using the configurator, you may have some changes that need to be persisted even after some posterior push from this repo. I mean... how do you make sure pushes from here are not overwriting "selections" made by admins using the configurator? Just curious...

[yuvipanda]

Great question, @damianavila!

1. https://github.com/yuvipanda/jupyterhub-configurator/blob/317759e17c8e48de1b1352b836dac2a230536dba/jupyterhub_configurator/mixins.py#L25 is run just before start, so it overrides everything set in this repo. So no matter what, configurator config takes precedence.
2. To minimize confusion, we should try set defaults for the traitlets that the configurator controls in the JSON schema for the configurator, not in the YAML in this repo. I don't think this is fully true now, but that is where we should aim.

Does this help, @damianavila?

[damianavila]

Yes, this helps... so if the configurator always takes precedence, you will only expose a subset of options preventing them to get more resources than it should take, right? I am thinking about how to prevent them from self-assigned more CPU and RAM than they should be self-provisioning... looking quickly into the configurator repo I see some schemas that should restrict what the admins can customize, am I right? Where that schema lives inside the pilot-hub repo? I see some schema here: https://github.com/2i2c-org/pilot-hubs/blob/master/hub-templates/base-hub/values.yaml#L126, is that the one I am should be looking at?

[yuvipanda]

@damianavila it was confusing for me too, so I opened #350 to try document that. It's brought up useful questions on what should be where.

[choldgraf]

I believe that the configurator has been updated a few times since the last time this issue was updated - where are we now on functionality of the configurator? Can we update the tasks above to reflect the steps needed to finish this off?

[damianavila]

I have updated the items completed accordingly to these docs: https://pilot.2i2c.org/en/latest/admin/howto/configurator.html
I think the list of tasks in the first message is still relevant unless we want to stop here and add the rest of the stuff as part of another issue. @yuvipanda has probably more context about the next steps.

[choldgraf]

Yeah - I think we should treat the tasks in this issue as a kind of "beta release" of the configurator - they should capture major functionality that needs to be there but not necessarily everything we'd want the configurator to do

[yuvipanda]

We have this deployed, and further work on self-serve of JupyterHub config will now be tracked in https://2i2c.productboard.com/feature-board/7803674-product-ideas/features/25998745/detail