User experience for a multi-hub service for University of Toronto

[choldgraf]

Context

We need to move the University of Toronto onto a multi-hub offering so that we can reduce the complexity of each hub and make the whole thing more maintainable. To do so, we need to propose what it "looks like" to offer a university multiple hubs. For example:

• How do you access a single hub?
• How do you figure out which hubs you have access to?
• Do administrators have some kind of visibility over all hubs and their activity?

Proposal

We should propose a general idea of what the admin and user workflow should look like for the University of Toronto.

Follow ups

This doesn't need to be perfect - we just need something that works for UoT and takes a step in the right direction. We can continue to refine this model as part of our broader efforts to improve our multi-hub services.

• ref: Define a multi-hub service offering team-compass#429

Updates and actions

No response

[yuvipanda]

I think I already sent a fairly detailed proposal to them on an email thread. Let's lift what's there, and start from there?

[colliand]

I looked for the email thread and think I found it! Pasting here:

Hello everyone! I just wanted to follow-up about next steps for
solving the problem of resource differentiation for multiple classes.
There are multiple decisions to be made here. They aren't mutually
exclusive, but we might want to prioritize some over others first.

Canvas Authentication?

Should we work on moving towards using Canvas (Quercus) for
authentication? The workflow for users would be the same, except
they'd be redirected to your Canvas installation rather than Microsoft
for authentication. This helps provide two additional features:

1. Users with Quercus guest accounts can also login to the hubs
   (https://edtech.engineering.utoronto.ca/content/request-guest-quercus-accounts)
2. We can potentially provide different resources (not environments)
   to different users based on the classes they are enrolled in. So if a
   subset of users require 8GB of RAM, this is possible to do with some
   work, as we can fetch list of classes a student is enrolled in via
   Canvas.

The big pro for this is that the user experience doesn't change at all
(unlike with multiple hubs), and you can do resource differentiation
easily. The con is that this would require some development work (that
we'd quote you for) to polish up the CanvasAuthenticator for
JupyterHub. It'd of course be OSS, and generally useful for a lot of
people :)

Multiple hubs

Regardless of what we do with Canvas, if we want to provide different
environments for different people,
we should support multiple hubs running on the same cluster. These
will all have very similar config, but differ in terms of environment
(image) and resource usage.

You could have [classname.jupyter.utoronto.ca](http://classname.jupyter.utoronto.ca/),
[r.jupyter.utoronto.ca](http://r.jupyter.utoronto.ca/), [dept.jupyter.utoronto.ca](http://dept.jupyter.utoronto.ca/), based on policies
for 'who gets a hub'.
https://docs.datahub.berkeley.edu/en/latest/policy/policy_create_hubs.html
is the policy berkeley uses, which basically boils down to:

1. Do they need a new environment that is complex?
2. Does this need significantly more resources?
3. Is there social capital to be had by explicitly supporting a
   department / use case?
4. Does it allow us to test something without impacting others?

Note that we haven't felt the need to restrict users based on their
classes - in our experience,
we haven't found users trying to access hubs for classes they aren't
enrolled in to get extra resources, and
not restricting users has made our lives a lot simpler.

This doesn't require any custom dev work, but we'll have to figure out
some pricing changes to accomodate the extra operational work this
generates.

Explore a shared responsibility model?

Jeremy suggested during the meeting that we explore ways some
responsibility could be offloaded to IT at UToronto. We at 2i2c have
been exploring a 'shared responsibility model' where folks from
Toronto take on some specific responsibilities, and we work with them
to make that happen. More details at
https://docs.2i2c.org/en/latest/about/shared-responsibility.html. At a
short glance, we could find some way to train and work with someone
from Toronto who can be responsible for the following tasks:

1. (If Canvas integration is done) Configuring which classes get what resources
2. (If we get new hubs) Making new hubs when required
3. Routine image modification requests

Questions to be answered

Given UToronto's Fall term starts sometime September, I think the next
immediate questions to be answered are:

1. Is there interest in this shared responsibility model? We'll have
   to figure out resourcing, pricing and an onboarding process this.
2. Should we start offering multiple hubs? If so, I'll work out a
   pricing model for that.
3. Should we move to Canvas authentication (with resource
   differentiation) before that? If so, I'll work out a development quote
   for that.

Excited to move forward with this!