Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

create dev hub for us to play with #4443

Open
shaneknapp opened this issue Apr 5, 2023 · 7 comments
Open

create dev hub for us to play with #4443

shaneknapp opened this issue Apr 5, 2023 · 7 comments
Assignees
Labels
enhancement Issues around improving existing functionality jira Issue tracked in JIRA priority: medium Medium priority tasks

Comments

@shaneknapp
Copy link
Contributor

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?).

@gmerritt
Copy link
Contributor

gmerritt commented Apr 5, 2023

This looks great. I'm looking forward to the discussion/decisions & giving this a go!

@shaneknapp shaneknapp added enhancement Issues around improving existing functionality priority: medium Medium priority tasks labels Apr 5, 2023
@balajialg
Copy link
Contributor

Sounds like a great idea. This hub could host experimental use cases like #4273

@ryanlovett
Copy link
Collaborator

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.

@shaneknapp
Copy link
Contributor Author

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.

@shaneknapp
Copy link
Contributor Author

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. :)

@balajialg
Copy link
Contributor

balajialg commented Apr 5, 2023

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.

@shaneknapp
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Issues around improving existing functionality jira Issue tracked in JIRA priority: medium Medium priority tasks
Projects
None yet
Development

No branches or pull requests

4 participants