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 напрямую. Это опасно по двум причинам:

map общая и mutable, а dynamic onboarding меняет ее во время работы процесса;
часть helper-ов и startup path продолжают жить как будто список namespace-ов immutable.

Полный rewrite в один шаг дал бы слишком большой blast radius. Поэтому сначала вводится thread-safe snapshot API в namespace layer, а затем существующие потребители переводятся на него по одному.

План шага 1

Добавить в pkg/utils/namespace.go методы snapshot для plain namespaces и namespaces with options.
Перевести pkg/utils/informer.go на snapshot API.
Перевести startup factory path в pkg/executor/executor.go на snapshot API.
Добавить unit tests для snapshot behavior.
Прогнать go test ./pkg/utils/... ./pkg/executor/....

Ожидаемый эффект

меньше прямых чтений общей map;
появление базового API, через который дальше можно выносить единый NamespaceManager;
нулевое изменение внешнего поведения на этом шаге.

Что НЕ делаем на этом шаге

не исправляем watcher lifecycle;
не добавляем remove/delete semantics;
не трогаем router race и buildermgr dedup bug;
не меняем RBAC.

2.3 KiB Raw Blame History Unescape Escape