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

find_localhost: Try both hostname and hostname -f before raising #242

Merged
merged 5 commits into from
Dec 4, 2020

Conversation

albertvaka
Copy link
Contributor

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 but hostname -s still succeed, so this PR changes the code to try both before raising.

hostname -f might fail but hostname -s still succeed
@albertvaka albertvaka changed the title find_localhost: Try both hostname -s before giving up find_localhost: Try hostname -s before giving up Nov 18, 2020
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)
Copy link
Member

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)

Copy link
Contributor Author

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.

Copy link
Member

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

@albertvaka albertvaka changed the title find_localhost: Try hostname -s before giving up find_localhost: Try both hostname and hostname -f before raising Nov 19, 2020
mx-psi
mx-psi previously approved these changes Nov 19, 2020
Copy link
Member

@mx-psi mx-psi left a 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

lib/dogapi/common.rb Outdated Show resolved Hide resolved
Co-authored-by: Hippolyte HENRY <zippolyte@users.noreply.github.com>
@albertvaka albertvaka merged commit a7eddf9 into master Dec 4, 2020
@albertvaka albertvaka deleted the albertvaka/hostname-fqdn-error-fix branch December 4, 2020 15:33
@zippolyte zippolyte added the changelog/Fixed Fixed features results into a bug fix version bump label Dec 7, 2020
albertvaka added a commit to DataDog/chef-handler-datadog that referenced this pull request Dec 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changelog/Fixed Fixed features results into a bug fix version bump
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants