Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make pscheduler-archiver-esmond reject null source/destination address #909

Closed
candlerb opened this issue Sep 6, 2019 · 1 comment
Closed
Assignees

Comments

@candlerb
Copy link
Contributor

candlerb commented Sep 6, 2019

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.

@mfeit-internet2
Copy link
Member

Closing since we've ended support for Esmond.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

No branches or pull requests

3 participants