Consider autogenerating schema for hub.config passthrough

[manics]

Proposed change

Thinking aloud.... hub.config.<class> allows arbitrary pass through of traitlets. The downside is it bypasses the Helm chart schema validation. Is it worth trying to autogenerate hub.config.<class> schemas for a subset of "supported" classes?

Alternative options

Do nothing.

Who would use this feature?

Anyone wanting to use pass-through configuration but still keep schema validation.

(Optional): Suggest a solution

See e.g. https://gist.github.com/manics/ce5ce8d05492ee3d1cf8217da14829c7 for a very preliminary proof-of-concept.

We could probably modify schema.yaml to contain custom metadata to indicate traitlets should be looked-up.
As part of this we could also include a deny-list of properties such as JupyterHub.base_url

[consideRatio]

Oooh... Yes if this could be made reliable enough and manage a few edge cases if needed, it could be something greatly improving the experience of using this chart.

We already do some generation based on schema.yaml, so, why not merge in additional parts?

This is similar to autodoc-traitlets for generating documentation based on traitlets configuration btw.

I figure the logic would be to allow unknown classes, but to be strict about a few known classes? Some possible issues could be specifying hub.config.KubeSpawner.something which is something inherited from the base class Spawner, would it be detected by our autoschema-traitlets functionality?

[minrk]

I see the sample script uses getmembers, but there's an easier way to get all configurable traits on any class:

config_traits = cls.class_traits(config=True)

I figure the logic would be to allow unknown classes, but to be strict about a few known classes?

Yes, I think so. Since folks can install additional packages, additional classes need to be allowed, though mistyping a class name is a likely source of typos the schema would like to catch.

I think it's also good to be loose about any traitlets we don't know how to handle. So give a type for the simple str/number/dict cases (already done by @manics), and then accept any type for any traitlet you don't recognize. I suspect the type validation is far less valuable than validating that you are using recognized keys. If the types are wrong, JupyterHub startup will fail informatively. It's the unrecognized keys where behavior is a lot harder to figure out and both more useful and easier to check via a schema.