Summary
The mariadb chart's Onyxia values schema doesn't expose a resources field in the launch form. As a result, users can't set CPU/memory requests and limits when starting a MariaDB service, and the chart deploys with no resources on its containers.
This breaks deployment on any namespace enforcing a ResourceQuota that requires limits.cpu/limits.memory: the pod is rejected with must specify limits.cpu/limits.memory. The postgresql chart from this same repo exposes resources and works fine on the same namespace.
Request
Add a resources section to the mariadb chart's Onyxia schema (values.schema.json), mapped onto primary.resources, with requests/limits sliders for CPU and memory — same as the resources.json schema used in helm-charts-interactive-services, and consistent with what postgresql already does.
Sensible defaults so the service works out of the box on quota-enforced clusters would be appreciated (e.g. requests 300m / 512Mi, limits 2 / 2Gi).
Summary
The mariadb chart's Onyxia values schema doesn't expose a
resourcesfield in the launch form. As a result, users can't set CPU/memory requests and limits when starting a MariaDB service, and the chart deploys with no resources on its containers.This breaks deployment on any namespace enforcing a
ResourceQuotathat requireslimits.cpu/limits.memory: the pod is rejected withmust specify limits.cpu/limits.memory. The postgresql chart from this same repo exposes resources and works fine on the same namespace.Request
Add a
resourcessection to the mariadb chart's Onyxia schema (values.schema.json), mapped ontoprimary.resources, with requests/limits sliders for CPU and memory — same as theresources.jsonschema used inhelm-charts-interactive-services, and consistent with what postgresql already does.Sensible defaults so the service works out of the box on quota-enforced clusters would be appreciated (e.g. requests
300m/512Mi, limits2/2Gi).