Create a BinderHub helm chart in the infrastructure repo

[sgibson91]

• Structurally, I'd imagine we'd make a 'binderhub' helm-chart, which has a dependency on both binderhub and dask-gateway. We can use condition to disable dask-gateway in future binderhubs that don't need this. A big problem here is the lack of composability in helm, and we will have to duplicate a bunch of things from our basehub and daskhub chart values.yaml files :( Is there any way to avoid this? We'd also need to make sure the z2jh version matches what we have in basehub, and I'm not sure how exactly to do that either.

Originally posted by @yuvipanda in #919 (comment)

• Project Board for this work

Tasks

• Scope and design a binderhub helm chart under the helm-charts folder in this repo

[sgibson91]

I have opened a very basic PR here: #1289

[sgibson91]

Some notes after chatting with @yuvipanda

• We are going to want to reuse some default values for this chart from basehub/daskhub, but helm is not very composable. Potential upstream work in the future may also change how our charts compose against z2jh. Hence we need a short-term hack to deploy this chart without bringing a lot of build complexity that we would have to undo later.
  • Simplest solution agreed upon was to copy-paste the default values we want, and then write a validation check that runs in CI that fails if the default values for basehub/daskhub have changed without being copied over to binderhub
    • Write validation test to check BinderHub's default values are up-to-date with basehub/daskhub #1402
  • Alternative option is to make this validation a pre-commit hook, but I thought this would be a rabbit hole for me since I haven't written one before and I'll get too excited. CI is the 'boring' option that will get me to move onto the next task more reliably 😅

• We should use https://github.com/sgibson91/bump-helm-deps-action to keep the binderhub chart dependency up-to-date with the upstream tags
  • Add bump helm chart versions workflow file #1391
• We should improve https://github.com/sgibson91/bump-jhub-image-action to (i) pull from quay.io, and (ii) be compatible with bumping the repo2docker tag in a binderhub chart values
  • Upstream improvements to sgibson91/bump-jhub-image-action #1308
• Test this chart in the 2i2c/pilot-hubs cluster
  • Deploying a MVP BinderHub #1404

• RE cryptomining:
  • ask mybinder team about upstreaming the tools they use
  • monero deployment from https://hackmd.io/3_UBXSW3T4Om3wv_buyZ-g
    • Enable cryptnono on all our clusters #1420
  • enable cilogon auth for now from Restrict cloudbank demo hub to edu & 2i2c users #1218

[damianavila]

Potential upstream work in the future may also change how our charts compose against z2jh

Can you drop some thoughts/details about this one? Thanks!

[sgibson91]

Can you drop some thoughts/details about this one? Thanks!

Chris wrote about it here #1382

[damianavila]

Chris wrote about it here #1382

I might be missing something... but I see high-level stuff on that issue (and there in proposal).
I was a little bit more interested in the technical details about:

change how our charts compose against z2jh

Feel free to point me out to existing notes/docs about that discussion if those already exist.

[sgibson91]

@damianavila I think the point is that we don't know. I'm not even sure if the BinderHub chart will even continue to exist if you can use repo2docker to built images directly in z2jh 🤷🏻‍♀️ Until that issue I linked to has more technical details, I can't say for sure what the future of this chart will be.