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
Currently the Core module receives registration requests from modules containing their name, address and current health. From that, it begins a health monitor using the address published to check if module continues to be up, repeating the calls in an interval.
This works fine for single-instance IP-based addresses, but doesn't work correctly with dns-based addresses or load-balancers like services in k8s.
To support this the module registry and the monitors in the Core module, will need to identify registered addresses and adapt mechanisms accordingly. The cases are the following:
A module registers into the Conduit "mesh" with IP address
A module registers into the Conduit "mesh" with a hostname
In the first case the process works in the same way as currently. Registering the module, health-checking using the address and publishing it to the rest of the mesh members. If another instance of that module registers itself, its address gets added into the pool of addresses for that module, it is individually health-checked and Core publishes the address according the gRPC name resolution spec: https://github.com/grpc/grpc/blob/master/doc/naming.md
In the second case, the module registry will first need to do a dns lookup of the hostname, receiving the list of addresses for that module. Due to the fact that instances cannot be uniquely identified from the initial request, the health status provided by the module will be ignored and a health check request will be done immediately to all received addresses (from the dns query) to populate health statuses for each instance. Then the resulting addresses are published in the same way as the 1st case.
In order to ease the workload in the gRPC sdk and module-tools libraries, the core module will publish separate events for healthy addresses and general addresses. So that modules can have the full list of instances, but also auto-connect only to addresses that have actually been validated. Which is similar to what is happening now.
The text was updated successfully, but these errors were encountered:
Currently the Core module receives registration requests from modules containing their name, address and current health. From that, it begins a health monitor using the address published to check if module continues to be up, repeating the calls in an interval.
This works fine for single-instance IP-based addresses, but doesn't work correctly with dns-based addresses or load-balancers like services in k8s.
To support this the module registry and the monitors in the Core module, will need to identify registered addresses and adapt mechanisms accordingly. The cases are the following:
In the first case the process works in the same way as currently. Registering the module, health-checking using the address and publishing it to the rest of the mesh members. If another instance of that module registers itself, its address gets added into the pool of addresses for that module, it is individually health-checked and Core publishes the address according the gRPC name resolution spec: https://github.com/grpc/grpc/blob/master/doc/naming.md
In the second case, the module registry will first need to do a dns lookup of the hostname, receiving the list of addresses for that module. Due to the fact that instances cannot be uniquely identified from the initial request, the health status provided by the module will be ignored and a health check request will be done immediately to all received addresses (from the dns query) to populate health statuses for each instance. Then the resulting addresses are published in the same way as the 1st case.
In order to ease the workload in the gRPC sdk and module-tools libraries, the core module will publish separate events for healthy addresses and general addresses. So that modules can have the full list of instances, but also auto-connect only to addresses that have actually been validated. Which is similar to what is happening now.
The text was updated successfully, but these errors were encountered: