TypeError: '<' not supported between instances of 'NoneType' and 'str'
shealym opened this issue · 8 comments
This seems related to #74 and #92 ... I'm getting the same error when trying to generate the Deployment Report, even if I repeat the command over and over:
[sas@AdminVM-Viya viya4-ark]$ python3 viya-ark.py deployment-report -n devtech-viya-ns
Generating deployment report......................DONE
Traceback (most recent call last):
File "viya-ark.py", line 139, in <module>
main(sys.argv[1:])
File "viya-ark.py", line 77, in main
command.run(argv[1:])
File "/opt/sas/viyainstall/tools/viya4-ark/deployment_report/deployment_report.py", line 48, in run
main(argv)
File "/opt/sas/viyainstall/tools/viya4-ark/deployment_report/deployment_report.py", line 149, in main
include_resource_definitions=args.include_resource_definitions)
File "/opt/sas/viyainstall/tools/viya4-ark/deployment_report/model/viya_deployment_report.py", line 705, in write_report
data_json = json.dumps(self._report_data, cls=KubernetesObjectJSONEncoder, indent=4, sort_keys=True)
File "/usr/lib64/python3.6/json/__init__.py", line 238, in dumps
**kw).encode(obj)
File "/usr/lib64/python3.6/json/encoder.py", line 201, in encode
chunks = list(chunks)
File "/usr/lib64/python3.6/json/encoder.py", line 430, in _iterencode
yield from _iterencode_dict(o, _current_indent_level)
File "/usr/lib64/python3.6/json/encoder.py", line 404, in _iterencode_dict
yield from chunks
File "/usr/lib64/python3.6/json/encoder.py", line 404, in _iterencode_dict
yield from chunks
File "/usr/lib64/python3.6/json/encoder.py", line 353, in _iterencode_dict
items = sorted(dct.items(), key=lambda kv: kv[0])
TypeError: '<' not supported between instances of 'NoneType' and 'str'
The Pre-Install Requirements report runs without issue. Thoughts? Thanks!
Hi @shealym, I've been looking into this issue and I haven't been able to reproduce the error you're seeing. To start, would you mind trying to run the deployment-report again? I just want to make sure there wasn't some temporary resource causing an issue that has since been cleaned up. If you are still seeing the issue after running the report again, we can try to narrow down the cause. Thanks!
Hey Josh, I re-cloned the code again today, but I'm still getting the issue every run. Any debug I can put in on this? Thanks for the help!
Hey @shealym, unfortunately there isn't a surefire debug option that would catch the issue. It stems from some key in the dictionary of data that the report collects being empty. It could be a key the report generates, but it could also just be something that's returned from K8s so we wouldn't be able to effectively detect it. There is a fairly simple modification to the code that can be made to help generate something that can be evaluated.
On line 705 in viya4-ark/deployment_report/model/viya_deployment_report.py change:
data_json = json.dumps(self._report_data, cls=KubernetesObjectJSONEncoder, indent=4, sort_keys=True)to:
data_json = json.dumps(self._report_data, cls=KubernetesObjectJSONEncoder, indent=4, sort_keys=False)Once the file is updated, you can rerun the report with the -d option, which will only generate the data file (basically, a dump of the data dictionary structured as JSON):
python3 viya-ark.py deployment-report -n devtech-viya-ns -dOnce that file has been generated, a grep for "null": should help narrow down the culprit. If you find a null key in the file, if you could please attach a snippet of the JSON with some context, that can help us determine why a null key exists. Thanks!
Hey Josh, it's in this section:
"discoveredResourceTypes": {
"pods": {
"available": true,
"count": 17,
"kind": "Pod",
"sasCRD": false
},
"jobs.batch": {
"available": true,
"count": 46,
"kind": "Job",
"sasCRD": false
},
"null": {
"available": false,
"count": 0,
"kind": null,
"sasCRD": false
},
"cronjobs.batch": {
"available": true,
"count": 5,
"kind": "CronJob",
"sasCRD": false
},
"pgclusters.webinfdsvr.sas.com": {
"available": true,
"count": 1,
"kind": "Pgcluster",
"sasCRD": true
},
"nodes": {
"available": true,
"count": 5,
"kind": "Node",
"sasCRD": false
},
"configmaps": {
"available": true,
"count": 255,
"kind": "ConfigMap",
"sasCRD": false
},
"secrets": {
"available": true,
"count": 58,
"kind": "Secret",
"sasCRD": false
},
"services": {
"available": true,
"count": 176,
"kind": "Service",
"sasCRD": false
},
"casdeployments.viya.sas.com": {
"available": true,
"count": 1,
"kind": "CASDeployment",
"sasCRD": true
},
"opendistroclusters.opendistro.sas.com": {
"available": true,
"count": 1,
"kind": "OpenDistroCluster",
"sasCRD": true
},
"httpproxies.projectcontour.io": {
"available": false,
"count": 0,
"kind": null,
"sasCRD": false
},
"espconfigs.iot.sas.com": {
"available": true,
"count": 1,
"kind": "ESPConfig",
"sasCRD": true
},
"esploadbalancers.iot.sas.com": {
"available": true,
"count": 0,
"kind": "ESPLoadBalancer",
"sasCRD": true
},
"esprouters.iot.sas.com": {
"available": true,
"count": 0,
"kind": "ESPRouter",
"sasCRD": true
},
"espservers.iot.sas.com": {
"available": true,
"count": 0,
"kind": "ESPServer",
"sasCRD": true
},
"espupdates.iot.sas.com": {
"available": true,
"count": 0,
"kind": "ESPUpdate",
"sasCRD": true
},
"virtualservices.networking.istio.io": {
"available": false,
"count": 0,
"kind": null,
"sasCRD": false
},
"routes.route.openshift.io": {
"available": false,
"count": 0,
"kind": null,
"sasCRD": false
},
"ingresses.networking.k8s.io": {
"available": true,
"count": 161,
"kind": "Ingress",
"sasCRD": false
},
"ingresses.extensions": {
"available": true,
"count": 161,
"kind": "Ingress",
"sasCRD": false
}
},
"cadenceInfo": "Stable 2021.2.1 2021.2.1 (20211213.1639416437442)",
Thanks!
Hi @shealym, thank you for capturing that information. That is perfect. I'm going to dig into this today and I'll let you know when I have something that should work for this issue. Thanks again!
Hi @shealym, sorry for the delay. I've pushed a change to a development branch that I'm hoping will resolve the issue you're seeing. Because I wasn't able to reproduce this issue, I was hoping you could run a test and make sure the issue is no longer encountered.
When you have a chance, please pull or re-clone this project, checkout the development branch, issue_161, to access the code with the fix, and then run the deployment report as you normally would. Please let me know if this yields the results you were expecting. Thanks!
Hey Josh, apologies for the late reply to this. I pulled the development branch earlier today, and the Deployment Report ran successfully. Thanks for the help!
This Issue is addressed in Release 1.8.0