-
Notifications
You must be signed in to change notification settings - Fork 88
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
find_localhost: Try both hostname
and hostname -f
before raising
#242
Conversation
hostname -f might fail but hostname -s still succeed
lib/dogapi/common.rb
Outdated
begin | ||
out = Addrinfo.getaddrinfo(Socket.gethostname, nil, nil, nil, nil, Socket::AI_CANONNAME).first.canonname | ||
rescue SocketError | ||
out, status = Open3.capture2('hostname', '-s', err: File::NULL) |
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.
Do we actually want to use hostname -s
? Or should we use just hostname
? The reason why we bumped chef-handler was precisely because of a hostname -s
warning (see #57)
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.
Good catch. I wasn't aware that Windows didn't support that flag. I used -s
because on MacOS -f
is the default, so on those if hostname -f
fails, hostname
will also fail. We have two options:
- Change the
hostname
call we do depending on the platform - Remove the
-s
and assume that on Mac we will have one less error recovery option.
Given this error path should be uncommon (our two other ways to get the hostname must fail), I will go with the second option to not increase the code complexity.
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 like the second option more too, we can always add complexity later for macOS if we need to
hostname
and hostname -f
before raising
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! you need to merge master apparently
Co-authored-by: Hippolyte HENRY <zippolyte@users.noreply.github.com>
To include DataDog/dogapi-rb#242
What does this PR do?
Potential fix for DataDog/chef-handler-datadog#126
Since #219 we raise if we can't resolve the hostname. Before that (I believe) we returned an empty string, The previous behaviour is not what we want, but raising an exception now makes the problem more obvious. It seems that
hostname -f
might fail buthostname -s
still succeed, so this PR changes the code to try both before raising.