Spike: split out custom config#8338
Draft
agoose77 wants to merge 1 commit into
Draft
Conversation
Contributor
|
Merging this PR will trigger the following deployment actions. Support deploymentsNo support upgrades will be triggered Staging deployments
Production deployments
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Our JupyterHub config is quite large (1701 lines). Much of this is inline vendored Python. Through time, this has been tested, but if we were to write this from scratch it would be a difficult exercise to avoid introducing string formatting bugs and other problems.
This PR is a spike to pull out the config files into lint-able files. The problem with this spike is that the JupyterHub deployment does not depend upon the checksum of the configmap, so changes to these config files do not lead to a hub restart. It seems quite difficult to plumb that feature in to the base chart, and I suspect that's a good reason for why things are done this way at the moment.
CC @GeorgianaElena because it's relevant to our quarterly objective, but I'm not asking any time from you here!
Some questions:
postinstallhook here to trigger a hub reload? Is that acceptable as additional moving parts? https://helm.sh/docs/topics/charts_hooks/jupyterhub_config.d/foo/bar.pyautomatically.Note
I haven't tested this deployment.