There are scenarios like #2151 with Docker Swarm where the destination list needs to be dynamically resolved by DNS. This is different from what we support today in Destination configuration - although you can specify the destination host using DNS, it is expecting that to be a single host, and not a collection of hosts that needs to be used as the basis for load balancing.
In addition you want the host resolution to be dynamic, and constantly polling for changes to the DNS records as additional hosts can be added/removed. It could also be tied in with passive health checks, so that in the case of a failure, that can be a signal to poll the dns to see if the host is still listed, and if not what the alternatives are.
In this scenario, the DNS server with the addresses may not be the default for the host, and the DNS api built into .NET just uses the host platform's APIs for DNS resolution. This scenario may justify using a separate dns client such as DnsClient.NET which can be used to talk to the DNS server directly.
A DNS IProxyConfigProvider would implement the Cluster part of configuration and would populate the cluster properties based on an IConfiguration Section, except rather than having each destination explicitly enumerated, it would use DNS to resolve the host list, and poll/listen for dns changes and update the configuration as applicable.
However there are some problems with this concept:
IProxyConfigProvider's can't overlap - they can supply unique objects, but they can't add extra info to each other
IProxyConfigFilters can adjust config coming from another provider, but they can't invalidate and update configuration
ConfigurationConfigProvider is sealed and most of its members are marked as private, so you can't just re-implement the CreateCluster method calling into the sub-routines that will parse out HttpClient, HealthChecks etc from IConfiguration.
We should fix one or all of the above to make this kind of scenario easier to implement.
There are scenarios like #2151 with Docker Swarm where the destination list needs to be dynamically resolved by DNS. This is different from what we support today in Destination configuration - although you can specify the destination host using DNS, it is expecting that to be a single host, and not a collection of hosts that needs to be used as the basis for load balancing.
In addition you want the host resolution to be dynamic, and constantly polling for changes to the DNS records as additional hosts can be added/removed. It could also be tied in with passive health checks, so that in the case of a failure, that can be a signal to poll the dns to see if the host is still listed, and if not what the alternatives are.
In this scenario, the DNS server with the addresses may not be the default for the host, and the DNS api built into .NET just uses the host platform's APIs for DNS resolution. This scenario may justify using a separate dns client such as DnsClient.NET which can be used to talk to the DNS server directly.
A DNS IProxyConfigProvider would implement the Cluster part of configuration and would populate the cluster properties based on an IConfiguration Section, except rather than having each destination explicitly enumerated, it would use DNS to resolve the host list, and poll/listen for dns changes and update the configuration as applicable.
However there are some problems with this concept:
ConfigurationConfigProvider
is sealed and most of its members are marked as private, so you can't just re-implement theCreateCluster
method calling into the sub-routines that will parse out HttpClient, HealthChecks etc from IConfiguration.We should fix one or all of the above to make this kind of scenario easier to implement.