Closed consideRatio closed 3 months ago
I did a delayed self-review, and is now moving ahead merging this based on https://github.com/2i2c-org/binderhub-service/issues/57#issuecomment-2211180075 where I'll followup with testing it practically by doing https://github.com/2i2c-org/infrastructure/issues/4370
This makes for briefer resource names, while preserving the ability to deploy multiple instances in the same namespace. It also systematically introduces helper functions rendering various resource names, which is useful if a parent chart wants to reference them. Overall, this PR is making this chart align with how the jupyterhub chart behaves.
Naming changes
Breaking changes
Anything referencing these names will experiencing a breaking change, but if that isn't done, it may be fine to upgrade because there isn't a PV resource or similar being renamed that leads to data loss.
There is no way to exactly retain the existing naming as part of this change.
During upgrade when using an Ingress resource with ingress-nginx, you may run into an error like:
To handle that, just delete the old ingress resource first manually by
kubectl delete ingress ...
.Related docs
The jupyterhub chart has related docs on fullnameOverride.