deployer: don't generate config in deployer anymore

[GeorgianaElena]

Closes #1925

All hubs configs have been changed I've only added the config to the 2i2c-staging hub to get an early approval about the workflow, but it should be added eventually to all of the hubs. What do you think? (Checkout #1925 for more context)

already merged This is based off the work in #2277, so it should be merged after it.

Todo:

• update the remaing hubs config
• update infrastructure docs refs to the old config
• update https://github.com/2i2c-org/default-hub-homepage readme with how to configure hubs to use a custom branch

[damianavila]

❗ The only relevant change here can be checked out at GeorgianaElena@80cca07.

I would probably suggest merging #2277 first and then rebasing this one on top of main.

I've only added the config to the 2i2c-staging hub to get an early approval about the workflow, but it should be added eventually to all of the hubs. What do you think?

I concur, although should not be added to the basehub config instead? Well, you may be thinking about that when you say "it should be added eventually to all of the hubs", I presume.

[consideRatio]

This work is now unblocked by #2277 being merged and I'm excited about this follow up work!!

---

The PRs current approach is to duplicate the declaration of jupyterhub.hub.initContainers into each separate hub, at least that has provided customized login page configuration, because there is a reference to a branch name that should be configured per hub.

I'd like to see that instead of doing this, we let the basehub chart define a ConfigMap template that renders values we wish to be different per hub's initContainer. Then, we let the hub's added initContainer instead reference an environment variable, which we have mounted from the basehub's rendered ConfigMap.

Looking at the initContainers and extraContainers, I see only a branch name of relevance that differs. So I figure the following:

1. basehub adds a ConfigMap template that renders based on some variable we configure in values.yaml for basehub
2. basehub defines hub.initContainers and hub.extraContainers, but also lets the extra container defined that references a hub specific variable do that via a ConfigMap mounted environment variable.

Considering the right to replicate, I also suggest that we allow the github repo we git clone to be a basehub values configuration that is rendered by the configmap template and read as an environment variable as well.

[GeorgianaElena]

@consideRatio, thanks for the great suggestion of simplifying this and for the instructions! Take a look at the latest changes. I've left a comment with the tiny tradeoff that we will need to do (will also add a todo in the top comment to update the template repo docs) as part of this, but I'm super ok with it. LMK what you think.

[consideRatio]

This looks reasonable to me!

[consideRatio]

Nice!

I think thanks to the schema of minValues we can be certain that you have updated all hubs to have jupyterhub.proxy.hosts and jupyterhub.ingress.tls configuration.

I nitpicked about systematic naming for env vars, but this LGTM!

[consideRatio]

Wieeee no more chart config generation!!

If you have the energy, do a quick scan for documentation that may be outdated along with merging this - but otherwise 👍 for going for a merge!

[GeorgianaElena]

If you have the energy, do a quick scan for documentation that may be outdated along with merging this - but otherwise 👍 for going for a merge!

@consideRatio, I will add it to the todo list of this PR. And then Monday I'll do a pass through all of the todos left of the last 3 big PRs that I. merged 😅 to tighten all the loose ends 🚀

Thank you very much for your amazing feedback ❤️ 🎉

[github-actions]

🎉🎉🎉🎉

Monitor the deployment of the hubs here 👉 https://github.com/2i2c-org/infrastructure/actions/runs/4511416486