I recently found that in the traitlets file, it’s using GB (not GiB), and we are calculing GB as 1024 x 1024 x 1024 instead of 1000 x 1000 x 1000, is there something going wrong or I misunderstand the concepts? So GB should use base 10, and GiB should use base 2**10.
I also notice that in kubespawner documentation, it mentioned something similar, the storage_capacity
The reason I care about this is that I see AWS EC2 instance memory, they are using GiB and also a famous tool for provision nodes karpenter, they are also specifying memory with MiB instead of MB(usually used by the volume of hard disks). And we we specifying the GB to provisioning the node, it’s actually giving GiB instead, is it correct?
Yes, you’ve read it correctly. GB has been used ambiguously for many years. It might be nice to change JupyterHub to interpret GB as 1e9 (and add GiB to mean 2^30) following the official meanings, but that’s a breaking change.
storage_capacity is specific to KubeSpawner, the property is not shared by other spawners. It’s passed straight through to the Kubernetes API as an unmodified string.
Potentially we could add GiB as an alias for GB in JupyterHub, though would that add even more confusion?
Thanks for the clarification. I see that GB vs GiB problem itself could be confusing at the beginning already, and currently it’s more like a bug after looking into the differences between them. I wonder would it work if it supports both GB and GiB in the suffix dictionary as a formal fix?
still, after some thinking, I think you are right, this is not easy, and this fix might break user setups, probably it would help to start with some comments in the code.
