Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Enhancement]: Modify module monitoring and registry #1174

Open
kkopanidis opened this issue Sep 25, 2024 · 0 comments
Open

[Enhancement]: Modify module monitoring and registry #1174

kkopanidis opened this issue Sep 25, 2024 · 0 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@kkopanidis
Copy link
Contributor

kkopanidis commented Sep 25, 2024

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.

@kkopanidis kkopanidis added the enhancement New feature or request label Sep 25, 2024
@kkopanidis kkopanidis self-assigned this Sep 25, 2024
@kkopanidis kkopanidis added this to v0.17 Sep 25, 2024
@kkopanidis kkopanidis moved this to In Progress in v0.17 Sep 25, 2024
@kkopanidis kkopanidis added this to the v0.17 milestone Sep 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: In Progress
Development

No branches or pull requests

1 participant