layer1: fix newdeploy namespace parity step 5
This commit is contained in:
@@ -0,0 +1,29 @@
|
||||
# 2026-04-26 — NamespaceManager rewrite, step 5
|
||||
|
||||
## Цель шага
|
||||
|
||||
Исправить несимметрию между startup-path и dynamic namespace onboarding в `newdeploy` executor.
|
||||
|
||||
## Дефект
|
||||
|
||||
На старте `MakeNewDeploy()` регистрирует два вида обработчиков на Fission informers:
|
||||
|
||||
- `FunctionEventHandlers()`
|
||||
- `EnvEventHandlers()`
|
||||
|
||||
Но dynamic `AddNamespace()` регистрировал только `FunctionEventHandlers()`.
|
||||
|
||||
Это означало, что namespace, появившийся после старта процесса, обслуживается не тем же
|
||||
код-path, что namespace, известный на старте. Для multi-tenant Layer 1 это плохая семантика:
|
||||
часть поведения newdeploy зависит не от namespace, а от момента его появления.
|
||||
|
||||
## Исправление
|
||||
|
||||
В `AddNamespace()` добавляется регистрация `EnvEventHandlers()` перед запуском informer factory.
|
||||
|
||||
## Что НЕ меняем
|
||||
|
||||
- не меняем container executor;
|
||||
- не меняем poolmgr;
|
||||
- не добавляем remove semantics;
|
||||
- не меняем router.
|
||||
Reference in New Issue
Block a user