Implement the ConfigMap, Helm configuration regieme

[jdrivas]

• [x] Hub Service: Create a template to set default from Chart/Relase and a configuration parameter to define the HUB_SERVICE name. This has the default and a way to set it explicitly in the values.yaml.
• [x] Similar for PROXY_SERVICE name. This should also account somehow for the case where the proxy is internal and external.
• [ ] ServiceAccount: Create a template and configuration parameter for the names of the ServiceAccount. This is mostly a DRY issue.
• [x] Spawner: Add a configuration parameter to insert c.JupyterHub.authenticator_class. This is primarily for using DummyAuthenticator in testing etc. It's possible that want a separate config for that e.g. useDummyAuthenticator in the values file instead or as well as the configuration parameter.
• [x] Spawner: Add a configuration parameter for c.KubeSpawner.uid and c.KubeSpawner.fs_gid.
• [x] Storage: Add a configuration parameter for c.KubeSpawner.user_storage_capacity and consider adding params for c.KubeSpawner.user_storage_pvc_ensure and/or `c.KubeSpawner.storage_access_modes.
• [ ] Storage/Notebooks: Add a configuration parameter for c.Spawner.notebook_dir
• [x] Storage: Add a configuration parameter for c.KubeSpawner.pvc_name_template
• [x] Notebooks: Add a configuration parameter for c.KubeSpawner.image_pull_policy
• [x] Notebooks: Add a configuration parameter for c.KubeSpawner.image_spec
• [ ] Notebooks: Add a configuration parameter for c.Spawner.cmd and c.Spawner.args
• [ ] Notebooks: Add a configuration parameter for `c.KubeSpawner.profile_list

In the above, configuration parameter means an entry in the Values file that can then be read by jupyterhub_config.py. That file is stored on the Docker image and so not available to Helm for Values interpolation. This means that the Values have to be inserted into the configuration file during deployment somehow. The preferred mechanism would seem to be a Kubernetes ConfigMap. The question then is how do we get them into the configuration file.?

• The venerable Zero-to-Jupyterhub team does this by mounting the ConfigMap into /etc/jupyterhub/config.
• Perhaps it's a better idea to bring into the environment?

[jdrivas]

For the moment, we're going to initialize the PVC statically and simply instruct KubeSpawner how to mount volumes and claim from that static PBC.

After this works we'll configure KS to make the claim dynamically.

[jdrivas]

For the Service configuration.

• Take the directory that the file is defined in. e.g. Hub or Proxy as a default. This should not include Helm Release name or anything else. Use selection criteria for matching on that. The implications are that you will only have one kind of service per cluster ....... Not clear what to do. Perhaps for now we will include the Helm Release in the name thus: hub-production, hub-staging.
• Allow for a ServiceName to be over-ridden in the Values file.

[jdrivas]

There are a couple of ways to support config and the .py configuration file.

1. We can, essentially, recreate the Values file in a new Yaml file, that is then used as the data section for the configmap (this is essentially what the z2h folks did). Interestingly the z2h solution uses the form of ConfigMap that puts each Key into it's own file when mounted. The alternative, which I prefer, is to simply create a single yaml file, that is then read in to the config.py file as a one structure. Less frequent disk reads and Yaml translations (just one 'big' one). Less magic API. No get_value(....), just access the structure directly: config.foo.bar

2. We can try to interpolate the Values file in with a template File().asConfig directive. I expect this won't work, haven't tried it yet, but this would be the best solution as it would keep it down to a single file rather than a pair of files we have to keep in sync - which is never a good idea.

3. We could autogenerate the configmap from the Values file, not ideal but should only be required when we actually add entries to the Values file. This could be automated and incorporated to the git checkin process. Initial development will be a nightmare though.

I don't really like any of these options, except if 2 works they way I need it to.

[jdrivas]

Implemented and tested. The wiki contains a detailed explanation of what we're doing for coinfig.

The comment above is still relevant. We have more duplication than I would like, but are still striving for as much DRY as possible. The ConfigMap cannot be autogenerated from the Values file as not all elements are simply repeated from the Values file, some use helper templates. There really should be a better way, but we don't have it yet.