Onyxia improvement / helm charts values.schema.json

[Slim]

Hi onyxia team.
I'm opening this issue just to start a discussion. Let's just see where it leads us.

Context

We have our own onyxia instance running. And we have created some helm charts repositories to provide our own kind of services (using your library-chart base chart so that everything works fine with onyxia UI).

We are currently working on a new "Processes" tab section (we forked onyxia web), that is pretty the same thing as the services but instead of using kubernetes deployments/statefulset, we are using jobs, that are meant to run something (a job) and to end with a result.

On top of that, we are building a new API server that will implement the OGC API Processes specification.
The idea, in the end, is to be able to trigger and chain some processes in a pipeline.

Needs

To describe a process (which is basically, in this architecture, just a helm chart version), we need to specify the inputs that a process is able to take. And what's is great, it's that the OCG API Processes is asking those inputs to use a JSON schema fragment.

So we dig into values.schema.json included in the charts. We found that it is a file related to helm, and that you decided to take advantage of it to build the onyxia UI by adding some specific key:values in it. The thing is that those added values are onyxia specific, and are not used by helm to validate the services inputs. I'm now talking about services instead of our own implemention of processes because we think (but maybe we are wrong) that it could also be interresting for onyxia to take advantage of the helm validation of inputs (that is apply when running helm install). For example, we discover that today, it is possible to directly call the onyxia API with a CPU request/limit value outside of the sliders you provides in the values.schema.json, and that the request will succeed. If you/we were using a proper json schema with minimum, maximum and even multipleOf (to represent the slider's step) keys, then helm would validate the inputs at installation time and failed if they are not.
We are not JSON schema experts, but it looks like it's possible to manage a lot of use cases.

Ideas

• We know that it's possible to create a seperate file that will be included in the helm archive (for example: onyxia-ui.schema.json). That file could store onyxiaUI specific stuffs in it. That way, helm stuffs would be completely decoupled from onyxiaUI stuffs.
• Another idea would be to use a specific key in the values.schema.json, to gather all onyxiaUI objects (in fact, you already did that for some part of the file, with the x-onyxia key.)

We don't realize the amount of work it would take to achieve this and if it is something you are interresting in. So please give us your feedback about that.
Please also consider that we can help, as much as we can.

Regards

[Comte]

We are not utilizing the full potential of JSON schema in our standard Helm chart because it would impose the same limitations on CPU and memory for all charts based on ours.

This is why keeping the request and limit fields should remain within the UI-specific scope for creating open-source charts, similar to Bitnami charts.

We also maintain the same pattern as Bitnami for these specific UI fields.

Perhaps Onyxia-Web could also ensure that these JSON schema controls are directly implemented in the browser if some instances require a deeper utilization of features such as minimum, maximum, and required properties.

I am closing this issue. (Feel free to reopen it or create a new issue if some JSON schema controls are not well-implemented in Onyxia.)