From dd8bc1ddbafe72ad56dc1ad9f399d8a067d3c477 Mon Sep 17 00:00:00 2001 From: Paul Masurel Date: Thu, 26 Oct 2023 14:45:43 +0900 Subject: [PATCH] CR comments --- .../src/indexing_scheduler/scheduling/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/quickwit/quickwit-control-plane/src/indexing_scheduler/scheduling/README.md b/quickwit/quickwit-control-plane/src/indexing_scheduler/scheduling/README.md index 147ca627be0..a6be995f22d 100644 --- a/quickwit/quickwit-control-plane/src/indexing_scheduler/scheduling/README.md +++ b/quickwit/quickwit-control-plane/src/indexing_scheduler/scheduling/README.md @@ -7,7 +7,7 @@ This needs to be done under the constraints of: - not exceeding the maximum load of each node. (O) We also want to observe some interesting properties such as: -- (A) we want to keep the current state of the cluster. +- (A) we want to avoid moving indexing tasks from one indexer to another one needlessly. - (B) we want a source to be spread amongst as few nodes as possible - (C) we prefer to respect some margin on the capacity of all nodes. - (D) when we are working with the Push API source, we prefer to colocate indexers on @@ -27,7 +27,7 @@ optimization problem. In Quickwit, we have two types of source: amounts of historical data. Right now, the user is therefore expected to supply a desired number of pipeline. -Routers send their batch to the different ingesters they know off using a round-robbin logic. +Routers send their batch to the different ingesters they know using a round-robin logic. We assume that routers's list of known shards gets eventually updated after a shard addition, so that we can assume that shard have roughly the same load.