search

hashicorp / go-getter

Package for downloading things from a string URL using a variety of protocols.
Mozilla Public License 2.0
1.65k stars 232 forks source link

SRV Support Feature Request #86

Open huntercatalan opened 6 years ago

huntercatalan commented 6 years ago

I often download artifacts for nomad from my internal file servers which are operated by consul/nomad. I use consul DNS support and it's awesome. However, I am forced to put my file servers behind a load balancer (even though consul provides this support for free!) with a static port that becomes magic in my job config files. It would be great if go getter had support for SRV DNS support (and the rest of the hashicorp stack could inherit by extension). Old habits die hard and communities are opposed to making the standard "http://" schema do anything other than ":80" which is regrettable given the power of SRV DNS; luckily, go getter has the ability to execute "forced protocols." A new protocol could be added to perform the SRV DNS lookup and otherwise maintain complete backward-compatibility.

Example: service_discovery::http://internal.file.server.consul/my-files

Cheers

schmichael commented 6 years ago

Thanks @huntercatalan! This seems like a great use case to me. srv::... might be a more succinct and clear designation. Although the <proto>::<proto>... format is meant to force a protocol (eg http) with another (eg git), so reusing it for indicating srv might cause issues or be confusing. I don't think it's a blocker, but will take some discovery work to determine what the best indicator is.

tonyarkles commented 6 years ago

Just came across this and it seems like exactly what I'd need too for my current project.

0xabe1 commented 3 years ago

Bumping this issue, I’m interested as well. If this is 3+ years old, does this have a chance to happen?

srv::<proto> would be fine. Or, I’m not sure how port resolution works in go-getter, but we could make the port be the text string ‘srv’ (i.e. https://example.com:srv).