-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[NDMII-3058] Add synchronous rDNS lookup to rdnsquerier component #30002
Conversation
pkg/collector/corechecks/snmp/internal/report/report_device_metadata.go
Outdated
Show resolved
Hide resolved
Regression Detector |
pkg/collector/corechecks/snmp/internal/report/report_device_metadata.go
Outdated
Show resolved
Hide resolved
Test changes on VMUse this command from test-infra-definitions to manually test this PR changes on a VM: inv create-vm --pipeline-id=47487109 --os-family=ubuntu Note: This applies to commit c704f60 |
This PR no longer includes parts that were requested to change
The part of this PR that adds this to SNMP has been removed, this piece doesn't need a release note.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💯
/merge |
🚂 MergeQueue: pull request added to the queue The median merge time in Use |
What does this PR do?
This PR modifies the reverse DNS querier component to allow for synchronous calls.
Motivation
While this component was originally written with Netflow in mind, hence the asynchronous implementation, having a reverse DNS lookup with caching is also desired for 2 other use cases:
Describe how to test/QA your changes
Ensure that the asynchronous call still works and Netflow reverse DNS data is still being fetched properly. Changes to that were limited to renaming the function call.
Currently there's not a good way to QA the synchronous endpoint as this is just the addition of the synchronous call. Separate PRs will be created that actually use this code and impact the functionality of the agent.
Possible Drawbacks / Trade-offs
This isn't a perfect implementation. With more time, I would investigate refactoring the cache implementation to be more friendly to a synchronous approach. This would allow us to avoid having all of the channels to receive results.
Additional Notes