Major development Managed Hub Service v1

[choldgraf]

Summary

We should agree on the major development to do as a part of our Managed JupyterHub Service. This includes the major use-cases that we want to explicitly support, as well as features, tools, etc that we want to offer as a part of our JupyterHubs.

Acceptance criteria

This issue should contain a list of features and infrastructure setup we consider essential for 'v1', and track their progress for various cloud providers. The table should be ordered by priority.

Feature matrix

Feature	GCP	AWS	Azure
Self-serve images issue
GitHub Org / Team auth support issue
Access cloud object storage issue
Educational institution based auth support issue
Grafana with useful metrics issue
Self-serve resource config (RAM, CPU, etc) issue
Basic cloud costs monitoring and reporting issue
Monitoring for hub downtime issue
Automated deployment from CI issue	✅	issue
Autoscaling issue	✅	✅
Automated cluster setup issue	✅	issue	issue
Automated user homes setup issue	issue	issue
Backup user home directories issue		issue	issue
Backup jupyterhub databases issue
Put user image near cluster for faster pulls issue
Cheaper instances for dask-gateway issue	✅	✅	issue
Placeholders for faster node spinup issue
Appropriate resource requests for core pods issue
Cluster upgrade policy + implementation issue
z2jh upgrade policy + implementation issue

[choldgraf]

@yuvipanda I took a pass through the feature matrix and re-organized it a little bit. That said, I have two questions:

• I noticed that several of the things on there are not what I would call "features".

  In my mind, a feature is something that a user might ask for, so things like "backup jupyterhub databases" or "automate cluster setup" are more like optimization improvements, and I feel like those belong in Infrastructure Professionalization for the Managed JupyterHub Service v1 #611.

  Is it OK if I move some of these into that other issue and focus this one around user-facing features?

• Do we really need separate AWS/GCP/AZURE issues for each of these? Or should we instead have a single issue for each feature and assume that it will need to be deployed on each of the cloud providers before being closed, unless explicitly stated? I think the main question there is: in general, will it be a lot of unique work for each cloud provider, or will this often be "solve it for one, you get the others for free"?

[yuvipanda]

@choldgraf I was actually wondering if we could merge #611 and this. I am already finding myself at some sort of cognitive limit on what goes where. Can we unify it into a single 'things we need to do for v1'?

[choldgraf]

@yuvipanda hmm - I see why you'd like to combine them...some quick thoughts:

IMO, the larger an issue becomes (in terms of sub-issues that it links to), the less-valuable it will be. My plan was to use the "feature-focused" and "optimization-focused" issue like epics in an agile framework - a natural grouping of stories. I was then hoping to group these larger-level epics together for some rough "initiative-level" planning in this project board.

So maybe the scoping of these issues (one for 'features' and one for 'optimizations') is not sensible...but I don't think the answer is to just have one giant "things to do with infrastructure" issue with a list of other issues in it. I almost wonder if we should just dissolve this parent issue, and put each of the issues in the table above on one or two columns on the managed hub service board instead. Then we can just use the board (and the ordering of issues in each column) to make sure we don't forget important stuff. As an issue gets developed enough, we can add it to the backlog where it can then be worked on.

---

A meta point: I don't think that we should put a ton of time wondering "what should go where". The issues are dynamic and will update as we learn more, and we can always rearrange things. Moreover, we are all still inexperienced in these "agile" or "scrum" methodologies and so will continue learning over the coming months - who knows if we are using the right structure now. I think the important thing is that the issues we've got on the deliverables backlog are well-described, scoped, and high-quality, since that defines what we are doing in the next few sprints. (I say this as somebody who has read an unhealthy amount of blog posts and articles in the last three weeks trying to answer this question, so I am just as guilty of over-engineering our plans as anybody)

[choldgraf]

This conversation made me think that it'd be helpful for us to have a structured way of doing higher-level planning. It feels like using issues to track other issues is a bit problematic, because then you have issues at different levels of abstraction that are nested within one another. I wrote up a proposal for one way we could track this here: 2i2c-org/team-compass#182

[yuvipanda]

I think a lot has progressed since this issue, closing.

[choldgraf]

That is an understatement 😅