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
Use case(s) - what problem will this feature solve?
In cases where DNS is used by workloads for peer discovery, it may be necessary to make dynamic changes to allow traffic to flow from one failure domain to another. In such cases, the gRPC default polling interval of 30 minutes is too slow to allow for flexible traffic movement - it could instead be configurable for users who require more precise control over their traffic flow.
type BuildOption struct {
...
// PollingInterval is the minimum amount of time to wait
// between name resolution attempts.
PollingInterval time.Duration
}
This creates an implicit contract for Builder implementations to respect the provided configuration. Since I'm not familiar with what implementations of Builder exist beyond DNS, I'll defer to the maintainers to decide whether this is a good idea.
The usage would need to include some way to bubble this configuration up to the Client, for example:
This approach is kind of nice because the polling configuration can be isolated to the dns package. On the other hand, users must Register() the custom Builder inside an init() function, which generally occurs before any configuration can been loaded, which creates a bit of an awkward API surface.
Thanks for your consideration!
The text was updated successfully, but these errors were encountered:
Use case(s) - what problem will this feature solve?
In cases where DNS is used by workloads for peer discovery, it may be necessary to make dynamic changes to allow traffic to flow from one failure domain to another. In such cases, the gRPC default polling interval of 30 minutes is too slow to allow for flexible traffic movement - it could instead be configurable for users who require more precise control over their traffic flow.
Proposed Solution
Extend resolver.BuildOption to include additional configuration.
This creates an implicit contract for Builder implementations to respect the provided configuration. Since I'm not familiar with what implementations of Builder exist beyond DNS, I'll defer to the maintainers to decide whether this is a good idea.
The usage would need to include some way to bubble this configuration up to the Client, for example:
This isn't a great API, but 🤷♂I'm open to suggestions.
Alternatives Considered
Extend internal/resolver/dns to expose additional constructor options and re-export them in resolver/dns.
Usage would be something like:
This approach is kind of nice because the polling configuration can be isolated to the
dns
package. On the other hand, users mustRegister()
the custom Builder inside aninit()
function, which generally occurs before any configuration can been loaded, which creates a bit of an awkward API surface.Thanks for your consideration!
The text was updated successfully, but these errors were encountered: