44 lines
2.3 KiB
Markdown
44 lines
2.3 KiB
Markdown
# 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. |