You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Under certain unusual circumstances, it's possible for pscheduler-archiver-esmond to receive null from pscheduler.ip_normalize_version() for either source or destination address.
At the moment, it carries on regardless and sends this as metadata to esmond. Unfortunately, esmond accepts this with a 201 response, but creates an invalid archive. Furthermore, esmond accepts posts of test results to this invalid archive, also with a 201 response, but throws them away. This means that pscheduler archiver logs seem to show everything working correctly, when in fact no data is being stored. (Esmond probably ought to be more robust against those cases and return 4xx, but that's a separate issue)
As a simple remedy, I propose that an exception is raised in pscheduler-archiver-esmond if metadata['source'] or metadata['destination'] is None. This could be done as a last-ditch check before posting - or perhaps earlier in parse_addresses in esmond_util.py where a more useful error message could be given, saying which name and IP version had resolved to None.
As a secondary improvement, I'd like to suggest that if the test results contain information about the source and destination IP addresses used, it would be better to record that in esmond rather than re-resolving the hostnames. For example, the iperf3 test results seem to contain these addresses in start.connected.local_host and start.connected.remote_host
This would be closer to the source of truth about what actual IP addresses were used in the test. It could be useful in some other edge cases I've seen (e.g. a host has a static IPv6 address but has also picked up a SLAAC IPv6 address, and ends up using the latter for testing)
However, this implies that either the archiver would need to know details of the data structures from specific tests, or that a standardized way for tests to return the source/destination addresses would have to be defined.
The text was updated successfully, but these errors were encountered:
Under certain unusual circumstances, it's possible for pscheduler-archiver-esmond to receive null from
pscheduler.ip_normalize_version()
for either source or destination address.At the moment, it carries on regardless and sends this as metadata to esmond. Unfortunately, esmond accepts this with a 201 response, but creates an invalid archive. Furthermore, esmond accepts posts of test results to this invalid archive, also with a 201 response, but throws them away. This means that pscheduler archiver logs seem to show everything working correctly, when in fact no data is being stored. (Esmond probably ought to be more robust against those cases and return 4xx, but that's a separate issue)
As a simple remedy, I propose that an exception is raised in pscheduler-archiver-esmond if
metadata['source']
ormetadata['destination']
isNone
. This could be done as a last-ditch check before posting - or perhaps earlier inparse_addresses
in esmond_util.py where a more useful error message could be given, saying which name and IP version had resolved to None.As a secondary improvement, I'd like to suggest that if the test results contain information about the source and destination IP addresses used, it would be better to record that in esmond rather than re-resolving the hostnames. For example, the iperf3 test results seem to contain these addresses in
start.connected.local_host
andstart.connected.remote_host
This would be closer to the source of truth about what actual IP addresses were used in the test. It could be useful in some other edge cases I've seen (e.g. a host has a static IPv6 address but has also picked up a SLAAC IPv6 address, and ends up using the latter for testing)
However, this implies that either the archiver would need to know details of the data structures from specific tests, or that a standardized way for tests to return the source/destination addresses would have to be defined.
The text was updated successfully, but these errors were encountered: