-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Fix empty host.id
#4317
Fix empty host.id
#4317
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #4317 +/- ##
=====================================
Coverage 83.4% 83.5%
=====================================
Files 184 184
Lines 14350 14350
=====================================
+ Hits 11975 11983 +8
+ Misses 2149 2141 -8
Partials 226 226
|
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.
Should there be a test for this?
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.
I think this is a net improvement, we can continue discussing what the behavior should actually be in a containerized setup separately.
To me silently failing sounds like "there is no valid host.id
on this setup". This is not necessarily the case if we fail to read the files specified on the spec, since host.id
could also be a cloud provider ID (e.g. AWS EC2 instance id). But I don't have context on what other detectors do to have a strong opinion here.
This PR fixes the bug. There should be a new issue (enhancement) that should be about providing a |
|
Since |
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.
LGTM with the suggested CHANGELOG fix applied.
Co-authored-by: Robert Pająk <pellared@hotmail.com>
Fixes #4312.
When reading a non-existent file,
readFile
was returning"", nil
instead of"", err
resulting in an empty host id. The original intent was to return an error in this case, but this will make the example in #4312 (pasted below) panic:In a containerized environment, it's very likely that HostID detection will fail. That calls into question how we should handle this case. Should the
hostIDDetector
ignore errors and return an empty resource, or should it propagate the error (as per the original intent)? There is a similar detector in JS, but they work a little differently than the ones in the Go SDK. The HostDetector detects allhost.*
attributes. It will omithost.id
if it's not found, but return the other found attributes in a new resource. I think the Go SDK equivalent would be to make thehostIDDetector
a best-effort detector, and return an empty resource if it fails. Do any other detectors do this? Does anyone have thoughts or opinions? (cc: @mx-psi)