You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to the docs Logspout should look for a route address's DNS SRV records to figure out which ports to hit:
but you can also specify a name that resolves via DNS to one or more SRV records. That means this works great with Consul for service discovery.
This is not working in practice. Attempting to add a route using the example in the routesapi doc (which uses a format like loggregator.service.consul) simply results in an error: Bad route: missing port in address
Ideally, it seems like creating a common wrapper for Dial would be a nice place to put this code. Another option would be to put the DNS resolution code in its own function and just reference it from each transport.
Yea seems like this doesn't work right now. Maybe that quote was aspirational at one point. In any case, I'd accept a patch that had the string parsing/resolution in their own functions and have the udp and tcp transports call out to them like you described. Let me know if you have time to put that together; with tests please. Otherwise I'll get to it at some point in the next few weeks.
According to the docs Logspout should look for a route address's DNS SRV records to figure out which ports to hit:
This is not working in practice. Attempting to add a route using the example in the
routesapi
doc (which uses a format likeloggregator.service.consul
) simply results in an error:Bad route: missing port in address
Here's the actual API call I'm making:
And here's the response from
dig
(inside the container) showing valid DNS records being returned (including SRV):The text was updated successfully, but these errors were encountered: