Installation fails with Invalid type error for cpu value in the helm release set

[vizeit]

Bug description

To install custom configuration for a jupyterhub helm release using terraform, the values can be passed as yaml in the values parameter or as an individual value in the set parameter to the release function. When passing cpu value in the set parameter, zero-to-jupyter helm chart thrown the invalid type error and it is not possible to set the cpu value.

Error: values don't meet the specifications of the schema(s) in the following chart(s):
                  jupyterhub:
                       - singleuser.cpu.guarantee: Invalid type. Expected: [number,null], given: string

The example below provides different combinations that I tried and resulted into the same error

name  = "singleuser.cpu.guarantee"
type  = "auto"
value = "0.5"

name  = "singleuser.cpu.guarantee"
value = "0.5"

Also, if you try to pass memory values that are valid as per the K8 resource units specification, the spawner throws an error that the values are invalid
An example that is valid as per the specification but the spawner throws an error and single user pod fails to start,

name  = "singleuser.memory.guarantee"
value = "3.25Gi"

The workaround is to create a yaml file with cpu value and pass it to the values parameter

Note: I see that there was a PR 2870 made the type to string but was canceled

How to reproduce

1. Setup Terraform to install the release
2. Pass custom parameter for any pod cpu in the set
3. Execute installation using Terraform
4. The installation fails with the invalid type error for cpu

Expected behaviour

Kubernetes resource units are string values so the values for cpu (e.g. 250m, even though it can be described as 0.25) and memory should be accepted as a string value

Actual behaviour

JupyterHub installation fails

Your personal set up

Release version: 3.1.0

• OS:

• Version(s):

Full environment

# paste output of `pip freeze` or `conda list` here

Configuration

# jupyterhub_config.py

Logs

[acocamitiga]

I'm having the same problem! Any update?

[consideRatio]

Background:
Its a limitation in jupyterhub/kubespawner, stemming from being a class based on the general jupyterhub Spawner class that was created a long time ago, unrelated to k8s accepted syntax of specifying cpu/memory requests and limits.

Resolution idea:

• Make kubespawner accept k8d native syntax on the values for requests and limits for cpu and memory