search

2i2c-org / features

Temporary location for feature requests sent to 2i2c
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

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

Open choldgraf opened 2 years ago

choldgraf commented 2 years ago

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:

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.

Updates and actions

No response

yuvipanda commented 2 years ago

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 commented 2 years ago

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!