Open shaneknapp opened 1 year ago
This looks great. I'm looking forward to the discussion/decisions & giving this a go!
Sounds like a great idea. This hub could host experimental use cases like #4273
Yes, this will be great to have! I think it'd be cool to facilitate multiple dev environments:
I think we could use the profile_list feature of kubespawner and then prepare multiple profiles. For example one could start up a a11y image another could startup an octave image, etc. People would see a form when they login to the hub and could choose which to experiment with
This is an advanced feature we haven't used before, but I think it could be powerful for the tech dev team. It would help the team test different features simultaneously, without colliding with one another. It would also be eventually useful on the instructional hubs.
I'm not proposing this for the initial deployment of the dev hub, just for some point down the road.
Yes, this will be great to have! I think it'd be cool to facilitate multiple dev environments:
I think we could use the profile_list feature of kubespawner and then prepare multiple profiles. For example one could start up a a11y image another could startup an octave image, etc. People would see a form when they login to the hub and could choose which to experiment with
This is an advanced feature we haven't used before, but I think it could be powerful for the tech dev team. It would help the team test different features simultaneously, without colliding with one another. It would also be eventually useful on the instructional hubs.
I'm not proposing this for the initial deployment of the dev hub, just for some point down the road.
yes to all of the above! let's just get a basic dev hub up first, but in the short- to mid-term start experimenting with profile_list
.
Sounds like a great idea. This hub could host experimental use cases like #4273
we need to scope out the use cases for this hub and set some ground rules regarding what we should deploy there, vs breaking out in to a prod-style deployment (or addition to an existing hub).
i'm thinking that it would generally be a good idea to keep any deployments in the dev hub relatively ephemeral... experimental hubs are fine, but if we start to get Real Users[tm] logging in it should graduate to prod. :)
i'm thinking that it would generally be a good idea to keep any deployments in the dev hub relatively ephemeral... experimental hubs are fine, but if we start to get Real Users[tm] logging in it should graduate to prod. :)
Agreed. I was thinking that this hub could showcase some innovative use cases for a short period of time for instructors to explore a new usecase. As you said, none of these use cases as part of this hub should be deployed live in a course settings.
thoughts culled from the meeting: 1) canonical development environment in a hub? 2) (1) will allow us to deploy hubs from the dev hub 3) expands on @gmerritt 's VM idea 4) dev hub vs dev/ops hub (former is ephemeral, latter would be persistent) 5) tooling to ease creation of hubs (rather than a dozen manual steps) 6) @gmerritt to deploy a hub to test custom logos 7) confirm that the new-hub docs are accurate 8) terraform? probable a good idea to investigate further 9) d-lab wants to do their own dev work. are dev 'hubs' the right place for this? be careful of our workloads 10) custom images: binder and jh profiles 11) https://developer.hashicorp.com/terraform/cdktf
next week: greg deploy a new hub on shared node pool/filestore
this will be very useful, and a great way for us to test/deploy things w/o impacting balaji's work on a11y.
we can initially deploy this on the shared
small-courses
node pool and filestore instances. if it turns out to be necessary, we could also create a new node pool or filestore instance.this is also a great opportunity to both test-drive our docs and be the perfect opportunity to have @gmerritt learn how to create and deploy a hub!
https://docs.datahub.berkeley.edu/en/latest/admins/howto/new-hub.html
we'll need to decide what image we'll use, and discuss things like naming, prod/staging and CI integration (full? partial? none?).