Client: support unix scheme in NOMAD_ADDR

[xvello]

I am tunnelling access to remote Nomad/Consul hosts via ssh port forwarding. To avoid other processes hijacking the forwarded port, I am forwarding to local unix sockets.

While the consul client supports connecting with CONSUL_HTTP_ADDR=unix:///path/to/socket, the nomad command (v0.8.4) does not.

I plan on contributing this by porting the consul client logic into api.NewClient. would that be acceptable, although the agent does not (yet?) support binding it's http port to a socket?

[preetapan]

@xvello we would accept a patch that handles client logic, and modifying the agent to accept a socket address to bind to. Additionally, we would want to make it possible to disable HTTP binding on the client agent (by allowing -1 in the config to mean that http binding is disabled). If you are interested in implementing the feature in its entirety we welcome that as a PR.

[xvello]

thanks @preetapan, what's your next release timeline, so I can gauge the timing?

[xvello]

Hello, I have no use for this feature anymore, and nobody else has expressed interest for it so far.
I am closing this issue, but feel free to reopen it.

[github-actions]

I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

[schmichael]

All these years later and this is suddenly relevant again! Nomad 1.5 introduced the Task API as a unix socket within a task's directory. Sadly this bug still exists and makes the Task API obnoxious to use with our api package (you have to create a custom dialer).

https://developer.hashicorp.com/nomad/api-docs/task-api

We should really fix this and support unix sockets.