Simplify enabling / disabling dask-gateway for a hub

[yuvipanda]

While most hubs we offer do not need dask-gateway, some do. We want to support this in the easiest way possible. Currently, this is done via the daskhub chart in hub-templates/daskhub, which has a dependency on dask-gateway and hub-templates/base-hub. This lets us put dask specific config in hub-templates/daskhub/values.yaml.

This is extreme overkill, and causes problems in our deploy scripts - look at the amount of special casing for daskhub in deploy/. The only things the hub-templates mechanism offers is:

1. Conditional installation of a helm chart
2. Conditional setting of large swaths of config (currently in hub-templates/daskhub/values.yaml.

There should be simpler ways to accomplish both of these without resorting to a full extra chart.

[yuvipanda]

I've removed the ephemeral-hub template in #361 as a precursor to this.

[yuvipanda]

My current idea is to turn our YAML config into jsonnet, a non-turing complete, expressive configuration language that is JSON native. I quite like it, and it was built primarily to generate k8s objects and similar deeply nested JSON structures - and works well for that. There are python bindings as well.

Particularly, it enables easy object overlays, one of the issues we have with our config.

However, it is a new language and adds complexity - I'd prefer to just leave things in python if we can.

[damianavila]

In this case, I think the cost of adopting a new language is less than the complexity around the hierarchical structure and all the specific code to handle that special case.

[yuvipanda]

Thinking of dask as an additional service we want to deploy with JupyterHub, BinderHub is too! And right now it's difficult to mix and match since we use inheritance of charts, rather than composing them. For example, https://github.com/jupyterhub/binderhub/blob/0b4462c0b1fb15e355b32b38b99c60f440666e94/helm-chart/binderhub/values.yaml#L56 is the jupyterhub block in binderhub, some that conflicts with the jupyterhub block in the dask hub chart. But there's no reason they need to conflict, and if we had a better way of composing them, it will be all good. We'll end up with linear complexity rather than the combinatorial one we have now.

I think @jacobtomlinson talked about this too, and so did @rabernat

[choldgraf]

if we had a better way of composing them, it will be all good.

This feels like a good summary of a good chunk of the reason for jupyterhub/team-compass#382

Agreed that making this more straightforward would be very impactful, "composability" and "modularity" seems like things we should be striving for!

[choldgraf]

Hey all - I am going to remove this from the activity board since it feels like a more complex multi-week project rather than a 2-3 day project.

[consideRatio]

I'll go for a close here in favor of #3252 linking back to this. Its a big deal for us to transition to put dask-gateway under basehub, so it is an issue more narrowly focused on initial steps towards that.