layer1: add namespace snapshot api step 1

2026-04-26 09:30:51 +03:00
parent 27a280bc03
commit c987fa07e8
5 changed files with 114 additions and 7 deletions
@@ -0,0 +1,44 @@
+# 2026-04-26 — NamespaceManager rewrite, step 1
+
+## Цель шага
+
+Начать bounded rewrite Layer 1 без большого взрыва по коду.
+Первый шаг deliberately узкий:
+
+- не менять lifecycle namespace onboarding;
+- не трогать watcher-ы executor/router/buildermgr;
+- не менять контракты `AddNamespace`;
+- убрать первые прямые проходы по общей mutable map `FissionResourceNS`.
+
+## Почему именно так
+
+Сейчас multi-tenant логика уже динамическая, но многие старые code path все еще читают
+`DefaultNSResolver().FissionResourceNS` напрямую. Это опасно по двум причинам:
+
+1. map общая и mutable, а dynamic onboarding меняет ее во время работы процесса;
+2. часть helper-ов и startup path продолжают жить как будто список namespace-ов immutable.
+
+Полный rewrite в один шаг дал бы слишком большой blast radius. Поэтому сначала вводится
+thread-safe snapshot API в namespace layer, а затем существующие потребители переводятся
+на него по одному.
+
+## План шага 1
+
+1. Добавить в `pkg/utils/namespace.go` методы snapshot для plain namespaces и namespaces with options.
+2. Перевести `pkg/utils/informer.go` на snapshot API.
+3. Перевести startup factory path в `pkg/executor/executor.go` на snapshot API.
+4. Добавить unit tests для snapshot behavior.
+5. Прогнать `go test ./pkg/utils/... ./pkg/executor/...`.
+
+## Ожидаемый эффект
+
+- меньше прямых чтений общей map;
+- появление базового API, через который дальше можно выносить единый NamespaceManager;
+- нулевое изменение внешнего поведения на этом шаге.
+
+## Что НЕ делаем на этом шаге
+
+- не исправляем watcher lifecycle;
+- не добавляем remove/delete semantics;
+- не трогаем router race и buildermgr dedup bug;
+- не меняем RBAC.