--api should accept dns addresses

[anguslees]

Version information:

go-ipfs version: 0.4.16-92ac43a
Repo version: 7
System version: amd64/linux
Golang version: go1.10.3

Type:

Enhancement

Description:

I am running ipfs daemon on a home kubernetes cluster. The daemon runs fine. I would like to talk to the daemon's API port from another kubernetes pod, but the ipfs --api arg seems to only accept IP address literals (afaict?). In Kubernetes (and many other containerised) environments, the ipfs daemon's IP address is allocated dynamically, and can change on restarts. Services are usually found via DNS hostnames.

TL;DR: I want something like this to just work: ipfs --api /dnsaddr/api.ipfs.svc/tcp/5001

Right now that gives "Error: /dnsaddr/api.ipfs.svc/tcp/5001 is not a 'thin waist' address"

As far as I know, my only option right now is to wrap ipfs in some shell script that does a dns lookup and builds a /ip4/... address on the fly :(

[Stebalien]

For anyone fixing this: You'll need to use github.com/multiformats/go-multiaddr-dns to resolve the addr in apiClientForAddr in cmd/ipfs/main.go. You'll probably also want to feed in a context from the command.

[raulk]

@Stebalien – taking this one, if it's ok. The instructions were useful, thanks!

[Stebalien]

That would be awesome!

[raulk]

@Stebalien – The way I see it we have several options:

• introduced a load-balanced form of http.Client that supports different strategies (failover, round-robin, etc. defaulting to failover such that all requests are routed to the same backing client until a failure happens).
• use net.Dial to test routability to each address, and pick the first one that succeeds.
• create a http.Client for each result, dispatch a version command to each sequentially, and select the first one to respond successfully.
• fail if the DNS lookup returns multiple results (not recommended).
• pick the first lookup result (simplest solution).

Any thoughts?

@overbool – sorry, I had already been working on this issue as stated above! Happy to hear your thoughts, and if you'd like to collaborate on this one, or how else you'd like us to proceed!

[anguslees]

Just try each address in the order the DNS server gave them to you is what a "normal" Unix/C client does when it gets multiple DNS responses.

"Fancy" clients like web browsers usually do something more complex like try address families in parallel, etc.

[raulk]

@anguslees agree, I was thinking along those lines too for now.

Here's an initial stab to see if I'm headed in the right direction => raulk@c833393

Tests missing. Do we want to set specific timeouts for DNS resolution and socket tests?

[raulk]

@anguslees – I've done a bit more thinking. Ultimately I think we want to wrap all DNS results (IP addrs) in the HTTP client, and have the latter perform the failover in the order they were received.

But given the decentralised nature of IPFS, this could introduce some inconsistency as the IPFS nodes behind each IP address could hold a different state. So there is a tradeoff:

a) Pick one IP address to build the client with. If it becomes non-reachable, client fails => consistent but non-resilient.
b) Create an HTTP client with multiple backing IP addresses in failover fashion. If one fails, move on to the next reachable one => more resilient but may see inconsistent results.

Ultimately I guess we want (b), but wanted to put these thoughts out there.

[Stebalien]

I'd just go with the simple solution and pick the first (don't try it, just use it). It's up to the user to make sure that the address is stable and works.

Eventually, we can do something smarter like pass the multiaddr into the commands lib and have that figure things out but the simple solution should be fine for now.

[raulk]

PR here => #5372.