---
# System prepended metadata

title: Planning Sept. 2021

---

# Planning Sept. 2021

## Ian's comments from the 2i2c slack

I'm not sure I'm up to speed, but I can leave a couple of thoughts. The work with CTLT so far has centred around providing a z2jh based replacement of https://ubc.syzygy.ca. As far as practical, this is supposed to be a drop in replacement and it seems to be progressing well. The last note I have from Bala is around authentication and that seems to be working now. We'll do some testing then hopefully start moving things over in the next month or two.

As for formal structures and other interactions with CTLT, I would expect that to start by looking at exceptions to the current usage patterns. Specifically, if we set aside current usage on https://ubc.syzygy.ca we can examine things which "don't fit" and propose 2i2c based plans for them. We have some existing hubs (and I'm sure there are others planned) which would be good candidates to handle this way. Some (most?) of these are currently handled through delegated AWS accounts with CTLT's responsibility ending at the delegation. 

I don't think it is hard to imagine them (CTLT) acquiescing to us running those through 2i2c as some sort of a pilot (modulo some practicalities discussed below). Once they have their feet we this way, they can wrap it up in a more formal process and as time goes on more things probably fall out of the ubc.syzygy.ca basket and into one of these hubs.

Ultimately, CTLT is probably the right level for instructors or departments to make requests which are then fulfilled via 2i2c. To make that work, CTLT will need a process for evaluating proposed hubs, setting pricing, controlling hub lifespans etc. but they aren't sure how to do that yet. 
I think there's an opportunity to do some 2i2c pilots as discussed above and provide them with more certainty around these things. We could help them gather usage information and better understand the operation, management and support aspects a bit better.

For the practicalities, I can imagine some of the sticking points being residency and ownership/billing. Running in AWS Canada should satisfy residency requirements (seems to for ubc.syzygy.ca) and for ownership/billing they're currently (at the pilot scale) just delegating accounts, so hopefully they would view this as a small shift and work with us to learn a bit more.
I have one last latent point thing I always come back to when I think about this stuff; when we have lots of hubs we need to think carefully about decoupling them from user storage. From a student perspective I would expect my "stuff" to follow me wherever I go, and not be tied to a particular course or even institution. I think that's pretty fundamental to any practical long term program.



Ultimately the instructors and departments are likely to want them to foot the bill for any tech used in teaching. In a more sustainable future I would see them as being UBCs primary client of 2i2c (for teaching at least), and they would say "yes" or "no" to projects from specific instructors/departments which then get deployed via 2i2c. They would probably be involved at some level in management, escalating issues, life-cycling resources etc. but they're not quite there yet (I think).

In my post yesterday, I was proposing encouraging them to let us do a bit if exploration with some 2i2c pilots so that they can see how everything will work, what they need to monitor for costs etc. When they're a bit more comfortable, they can add admin or policies for allocation on top. Looking even further down the road, I can imaging instructors coming to them saying "I want a hub for PHYS400 to do XXX" and CTLT working with them to get the resource sizes right, set a lifetime for the hub and deal with any special requests (e.g. auth groups or data sources). Exactly how involved the instructors, departments and CTLT will be with each hub will probably vary, but at the end of the day CTLT will be the one paying the bill so they are probably going to be the ones to manage resource allocation.

## current hubs

* https://github.com/2i2c-org/pilot-hubs
* https://github.com/pimsmath/one-two-syzygy

## Other links

*  https://discourse.pangeo.io/t/future-of-pangeo-cloud-i-binder-for-everything/1574
*  https://github.com/eoas-ubc/eoas-ubc.github.io/blob/docs/pdffiles/Data_Science_Report_Sept2019.pdf 



## Possible projects

1. Funding 2i2c to accelerate feature development (like enhanced monitoring, additional quota tools) to the pilot hub

2. @Lindsey Heagy is part of a new graduate education project called PRODIGY -- https://www.nserc-crsng.gc.ca/Professors-Professeurs/Grants-Subs/CREATEResults-ResultatsFONCER_eng.asp  Lindsey, is there a budget line for computer resources in that grant?  Anything involving graduate/upper year remote sensing coursework is going to need hubs running on data lakes in US data centers, which could be managed by 2i2c

3. Dashboard hubs -- we are writing some plotly dashboards for our large enrollment climate courses hosted using jupyterhub and jhsingle-native-proxy (https://discourse.jupyter.org/t/new-dashboard-publishing-extension-for-jupyterhub/4202)   I think there's a good chance we could fund 2i2c to manage a hub like this if they wanted to spread out from the single pilot hub.
