layer1: fix buildermgr namespace dedup step 4
This commit is contained in:
@@ -0,0 +1,32 @@
|
||||
# 2026-04-26 — NamespaceManager rewrite, step 4
|
||||
|
||||
## Цель шага
|
||||
|
||||
Исправить реальный functional bug в dynamic onboarding buildermgr.
|
||||
|
||||
## Дефект
|
||||
|
||||
`buildermgr.StartNSWatcher()` вызывает:
|
||||
|
||||
1. `envw.AddNamespace()`
|
||||
2. `pkgw.AddNamespace()`
|
||||
|
||||
Но оба watcher-а используют один и тот же глобальный `nsResolver.AddNamespace()` для dedup.
|
||||
Из-за этого первый вызов добавляет namespace, а второй считает его уже обработанным и
|
||||
выходит раньше времени. В результате у динамического tenant namespace может подняться только
|
||||
Environment informer без Package informer.
|
||||
|
||||
## Исправление
|
||||
|
||||
1. Глобальный resolver обновляется один раз в `buildermgr/ns_watcher.go`.
|
||||
2. `environmentWatcher` dedup делает только по своей map `envWatchInformer`.
|
||||
3. `packageWatcher` dedup делает только по своим map `pkgInformer` / `podInformer`.
|
||||
|
||||
Так buildermgr становится симметричнее executor path: общий registry обновляется один раз,
|
||||
а конкретные компоненты сами решают, подписаны ли они уже на namespace.
|
||||
|
||||
## Что НЕ меняем
|
||||
|
||||
- не добавляем cleanup/remove semantics;
|
||||
- не меняем router;
|
||||
- не трогаем newdeploy parity gap на этом шаге.
|
||||
Reference in New Issue
Block a user