Closed pseudoyu closed 1 month ago
If a user runs multiple instances of the same worker with different block start/target configurations (not recommended but permissible), how should their indexing progress be displayed?
Currently, I select the larger one, but may lead to issues. @brucexc
If a user runs multiple instances of the same worker with different block start/target configurations (not recommended but permissible), how should their indexing progress be displayed?
Currently, I select the larger one, but may lead to issues. @brucexc
That approach should not happen often and is not endorsed. Operators should have sufficient knowledge when doing so themselves.
I think the status should stay unhealthy
until the operator reverts to 1 instance per worker.
If a user runs multiple instances of the same worker with different block start/target configurations (not recommended but permissible), how should their indexing progress be displayed? Currently, I select the larger one, but may lead to issues. @brucexc
That approach should not happen often and is not endorsed. Operators should have sufficient knowledge when doing so themselves.
I think the status should stay
unhealthy
until the operator reverts to 1 instance per worker.
I agree with this perspective. When multiple instances are simultaneously segmenting data for indexing, the status should be changed to unhealthy
. The reason is that the system lacks data from several different segments, which does not fulfill the requirements for being considered in an indexing state. The correct indexing
status should involve only one instance and should only be missing data from the current to the most recent update.
Summary
add worker progress in workers_status api
should Resolve #354
Checklist
Does this PR introduce a breaking change?