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

Improve end user reporting of hostname lookup errors #30

Merged

Conversation

mindjiver
Copy link
Contributor

The CanonicalHostName() method call is only best effors as stated in the
Java documentation:

"Gets the fully qualified domain name for this IP address. Best effort
method, meaning we may not be able to return the FQDN depending on
the underlying system configuration"

This means that we can experience failures if the system configuration
is such that when the swarm client is launched we can't determine our
hostname. Since swarm slaves are often spawned in public/private clouds
there might be some eventual consistency with regards to lookup of
hostnames. We try to help the situation by printing a somewhat
informative error message.

Using the '-name' command line option for this should have been a way to
work around this. However we where unconditionally performing this
lookup. Instead we now only perform the lookup of no name has been
provided on the command line.

Thanks to @jacob-keller who reported this.

Peter Jönsson added 2 commits July 20, 2015 22:08
The CanonicalHostName() method call is only best effors as stated in the
Java documentation:

   "Gets the fully qualified domain name for this IP address. Best effort
   method, meaning we may not be able to return the FQDN depending on
   the underlying system configuration"

This means that we can experience failures if the system configuration
is such that when the swarm client is launched we can't determine our
hostname. Since swarm slaves are often spawned in public/private clouds
there might be some eventual consistency with regards to lookup of
hostnames. We try to help the situation by printing a somewhat
informative error message.

Using the '-name' command line option for this should have been a way to
work around this. However we where unconditionally performing this
lookup. Instead we now only perform the lookup of no name has been
provided on the command line.

Thanks to @jacob-keller who reported this.
Catching multiple exceptions in the same catch statement is not support
in pre Java 1.7, so to support as many Jenkins installations as possible
to revert to copying the printouts to each exception block.
@mindjiver mindjiver force-pushed the improve-error-handling-for-canonical-hostname-lookup-failures branch from d745a8a to 3921eca Compare July 20, 2015 21:03
@jacob-keller
Copy link

This is great! I did some quick tests and it has helped prevent issues on my machines.

@jenkinsadmin
Copy link
Member

Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests

@mindjiver
Copy link
Contributor Author

It should just be to clone the repo and issue "mvn". A resulting Jenkins
swarm client uber jar should be in the tree afterwards.

Build requirements are java and maven. So pretty standard.

On Monday, July 20, 2015, Jacob Keller [email protected] wrote:

Thanks, this looks reasonable. What is the method for compiling this to
the jar format so I can give it a try?


Reply to this email directly or view it on GitHub
#30 (comment)
.

"It is often said that people who respect the importance of footwear are
the most successful, because they understand the value of working your way
up from the bottom."

mindjiver added a commit that referenced this pull request Jul 21, 2015
…nical-hostname-lookup-failures

Improve end user reporting of hostname lookup errors
@mindjiver mindjiver merged commit 96fbfce into master Jul 21, 2015
@mindjiver mindjiver deleted the improve-error-handling-for-canonical-hostname-lookup-failures branch July 21, 2015 18:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants