Node disk unit error? [ValueError: invalid literal for int() with base 10: '51175Mi']
Closed this issue · 1 comments
cnaslain commented
Hi,
Just ran the disk command with: python kube-node-usage.py --disk
but it fails with the following error:
# Kube-Node-Usage
# Release 2.0.0
# https://github.com/AKSarav/Kube-Node-Usage
Traceback (most recent call last):
File "/home/chris/workspace/Kube-Node-Usage/kube-node-usage.py", line 361, in <module>
main()
File "/home/chris/workspace/Kube-Node-Usage/kube-node-usage.py", line 352, in main
action(usagetype, sortby, isreverse, filternodes, filtercolors)
File "/home/chris/workspace/Kube-Node-Usage/kube-node-usage.py", line 165, in action
max_inmb=round(int(maximum) / 1024 / 1024)
ValueError: invalid literal for int() with base 10: '51175Mi'
From the kubectl get nodes -o json
command output; here is an example of the returned values:
"allocatable": {
"cpu": "40",
"ephemeral-storage": "50977832921",
"hugepages-1Gi": "0",
"hugepages-2Mi": "0",
"memory": "65491060Ki",
"pods": "110"
},
"capacity": {
"cpu": "40",
"ephemeral-storage": "51175Mi",
"hugepages-1Gi": "0",
"hugepages-2Mi": "0",
"memory": "65491060Ki",
"pods": "110"
},
Is this an issue with the k8s format?
For information, here is the version of k8s:
kubectl version
Client Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.4", GitCommit:"872a965c6c6526caa949f0c6ac028ef7aff3fb78", GitTreeState:"clean", BuildDate:"2022-11-09T13:36:36Z", GoVersion:"go1.19.3", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v4.5.7
Server Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.7+k3s1", GitCommit:"8432d7f239676dfe8f748c0c2a3fabf8cf40a826", GitTreeState:"clean", BuildDate:"2022-02-24T23:03:47Z", GoVersion:"go1.16.10", Compiler:"gc", Platform:"linux/amd64"}
Hope this will help.
Regards,
Chris
AKSarav commented
In the new release powered by Go Lang - I am not using Kubectl anymore and using K8s Client SDK and API - Please check if this resolves the issue - as I have reproduced this is no longer appearing
Thanks for pointing this issue - you were one of the reason for me to rewrite this implementation with K8s API instead of Kubectl