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
Go's resolver may try TCP if the UDP query results in a truncated response, so maybe this is not an issue. But it seems like Thanos is doing more than it needs to - there's a lot of overlap between the code in these two places.
Should Thanos delegate DNS resolution for peers to the memberlist library, and is there a compelling reason for it to do its own resolution as it is currently?
The text was updated successfully, but these errors were encountered:
The
resolvePeers()
function in thecluster
package tries to resolve the IP addresses for the cluster peers:https://github.com/improbable-eng/thanos/blob/19ff509a4f658887f90ab543c79cc821762f64cd/pkg/cluster/cluster.go#L423-L476
It does this using the Go DNS resolver.
The memberlist library does the same thing, but uses TCP first in a bid to retrieve as many peers as possible:
https://github.com/hashicorp/memberlist/blob/ce8abaa0c60c2d6bee7219f5ddf500e0a1457b28/memberlist.go#L303-L306
Go's resolver may try TCP if the UDP query results in a truncated response, so maybe this is not an issue. But it seems like Thanos is doing more than it needs to - there's a lot of overlap between the code in these two places.
Should Thanos delegate DNS resolution for peers to the memberlist library, and is there a compelling reason for it to do its own resolution as it is currently?
The text was updated successfully, but these errors were encountered: