From 1fe9e2c3458fbdfb762651f4d73d62386e6730b8 Mon Sep 17 00:00:00 2001 From: Jan Chaloupka Date: Mon, 5 Jan 2026 16:10:39 +0100 Subject: [PATCH] doc(Design Decisions FAQ): Why doesn't the framework provide helpers for registering and retrieving indexers for plugins --- CONTRIBUTING-descheduler.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/CONTRIBUTING-descheduler.md b/CONTRIBUTING-descheduler.md index 835c1a90d..0e5269374 100644 --- a/CONTRIBUTING-descheduler.md +++ b/CONTRIBUTING-descheduler.md @@ -20,3 +20,11 @@ These are the known conventions that are useful to practice whenever reasonable: * *no object instance duplication*: avoid duplication by no creating two objects with the same passed values at two different places. E.g. two nodes created with the same memory, cpu and pods requests. Rather create a single function wrapping test.BuildTestNode and invoke this wrapper multiple times. The aim is to reduce cognitive load when reading and debugging the test code. + +## Design Decisions FAQ + +This section documents common questions about design decisions in the descheduler codebase and the rationale behind them. + +### Why doesn't the framework provide helpers for registering and retrieving indexers for plugins? + +In general, each plugin can have many indexers—for example, for nodes, namespaces, pods, and other resources. Each plugin, depending on its internal optimizations, may choose a different indexing function. Indexers are currently used very rarely in the framework and default plugins. Therefore, extending the framework interface with additional helpers for registering and retrieving indexers might introduce an unnecessary and overly restrictive layer without first understanding how indexers will be used. For the moment, I suggest avoiding any restrictions on how many indexers can be registered or which ones can be registered. Instead, we should extend the framework handle to provide a unique ID for each profile, so that indexers within the same profile share a unique prefix. This avoids collisions when the same profile is instantiated more than once. Later, once we learn more about indexer usage, we can revisit whether it makes sense to impose additional restrictions.