search

devopsspiral / KubeLibrary

Kubernetes library for Robot Framework
MIT License
139 stars 38 forks source link

filter_pods_containers_statuses_by_name : TypeError: 'NoneType' object is not iterable #137

Open andyjsharp opened 11 months ago

andyjsharp commented 11 months ago

robotframework-kubelibrary==0.8.5

Noticed, that a test case was failing whilst we had an issue with our cluster dev environment, and that the the test produced the following output:

Traceback (most recent call last): File "/usr/local/lib/python3.10/site-packages/KubeLibrary/KubeLibrary.py", line 807, in filter_pods_containers_statuses_by_name for container_status in pod.status.container_statuses: TypeError: 'NoneType' object is not iterable While we know that there is an issue with the rabbitmq pod at this moment in time, I wasn't expecting the test to fail with this error. A snippit of the trace can be found here.

'status': {'conditions': [{'last_probe_time': None, 'last_transition_time': datetime.datetime(2023, 10, 3, 16, 37, 56, tzinfo=tzlocal()), 'message': '0/4 nodes are available: 1 node(s) had ' 'taint {node-role.kubernetes.io/master: ' "}, that the pod didn't tolerate, 1 " 'node(s) had taint ' '{node.kubernetes.io/disk-pressure: }, ' "that the pod didn't tolerate, 2 " "node(s) didn't match pod " 'affinity/anti-affinity rules, 2 ' "node(s) didn't match pod anti-affinity " 'rules.', 'reason': 'Unschedulable', 'status': 'False', 'type': 'PodScheduled'}], 'container_statuses': None, 'ephemeral_container_statuses': None, 'host_i_ps': None, 'host_ip': None, 'init_container_statuses': None, 'message': None, 'nominated_node_name': None, 'phase': 'Pending', 'pod_i_ps': None, 'pod_ip': None, 'qos_class': 'BestEffort', 'reason': None, 'resize': None, 'resource_claim_statuses': None, 'start_time': None}}] | '^rabbitmq$' ]

As can be seen in the data above, the container_statuses has returned as 'None', and this is then breaking the filter_pods_containers_statuses_by_name when it attempts to iterate with that result.

Can't say for sure how often we encounter this issue, and just something that I saw in our lab today.

andyjsharp commented 11 months ago

The more I think about this, probably the easiest way to handle this is just within Robot itself, with a TRY / EXCEPT... approach. To catch the TypeError as a result of the None response and handle it accordingly.