Fixes #50.

[dekobon]

I've been trying to execute the unit tests on my local workstation outside of the docker build environment. The tests were failing on IP parsing. Since this would be a quick fix, I went ahead and made the changes. Please tell me what you think.

[tgross]

LGTM once you add some tests, @dekobon. But...

I've been trying to execute the unit tests on my local workstation outside of the docker build environment.

...I feel like that shouldn't necessarily be supported. The reason we use Docker as the build platform is to avoid having to support every local configuration in existence; Golang developers in particular have a bad habit of making all kinds of assumptions about GOPATH and dependency management that we really don't want to get into.

[justenwalker]

Interesting, so it groups IPV4 and IPV6 addressed together.

@tgross - Maybe I'm over thinking this, but; Golang docs don't document this behavior. I hope we aren't relying something undocumented about the order in which these IPs are returned.

Should we instead split & parse these addresses and explicitly pick the one which is IPV4? Should we have a flag to prefer IPV4 over IPV6?

[misterbisson]

Should we have a flag to prefer IPV4 over IPV6?

@justenwalker and @tgross: do we need to ticket an issue to add IPv6 support to Containerbuddy (and for users to specify their preference)?

[dekobon]

You can peek at what golang is doing here: https://golang.org/src/syscall/netlink_linux.go

Also, it looks like we are in good company about IPV6 confusion: hashicorp/consul#529

Maybe we want to let the user specify what what IP to advertise.

[tgross]

Ensuring we have IPv6 support is likely to be a bit of extra effort to make sure we're not making IPv4 assumptions elsewhere in the code. Here's what I recommend:

• For this issue let's force the case of a IPv4/6 interface to select the IPv4 IP address by parsing the addresses as @justenwalker has suggested.
• And then let's open a new ticket per @misterbisson's suggestion to provide IPv6 support so that we can review the whole code base in that light.

[tgross]

This LGTM. I've opened #52 for further discussion of the IPv6 issue.