Description
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.