94 lines
5.7 KiB
Markdown
94 lines
5.7 KiB
Markdown
# 2026-04-26 — Layer2 chat handoff
|
||
|
||
## Что уже сделано
|
||
|
||
Layer1 завершён в ветке rewrite/layer1-namespace-manager-step1 и перенесён в новую рабочую ветку:
|
||
|
||
`rewrite/layer2-namespace-manager-api-step1`
|
||
|
||
Layer1 означает, что внутренняя адаптация Fission под multi-tenant namespace onboarding уже готова:
|
||
|
||
1. Вынесен общий `NamespaceManager`.
|
||
2. Buildermgr, router и executor/multitenant переведены на общий watcher/helper layer.
|
||
3. Summary/debug contract стабилизирован.
|
||
4. Logging path усилен и покрыт тестами.
|
||
|
||
Последняя точка закрытия layer1:
|
||
|
||
- commit `63ce6ea` — `layer1: close namespace manager step1`
|
||
|
||
## Какие тесты уже были прогнаны
|
||
|
||
Финальный целевой прогон для layer1:
|
||
|
||
`go test ./pkg/utils/... ./pkg/buildermgr/... ./pkg/router/... ./pkg/executor/multitenant`
|
||
|
||
Он прошёл зелёным.
|
||
|
||
## На какой ветке продолжать
|
||
|
||
Продолжать работу нужно на ветке:
|
||
|
||
`rewrite/layer2-namespace-manager-api-step1`
|
||
|
||
## Что является целью layer2
|
||
|
||
Layer2 — это уже не перепись watcher-ов, а внешний read-only consumption поверх готового `NamespaceManager` слоя.
|
||
|
||
Практическая цель:
|
||
|
||
1. Дать безопасный read-only status/debug/API surface для состояния multi-tenant namespace onboarding.
|
||
2. Не менять runtime behavior watcher-ов.
|
||
3. Не дублировать логику manager-а в service-level коде.
|
||
4. Использовать уже существующий `NamespaceManagerSummary`, а не придумывать вторую модель состояния.
|
||
|
||
## Что делать в новом чате
|
||
|
||
Новый чат должен стартовать не с переписывания layer1 заново, а с аккуратного поиска лучшей точки интеграции для layer2.
|
||
|
||
Предпочтительный порядок:
|
||
|
||
1. Проверить текущую ветку и чистоту дерева.
|
||
2. Найти существующий service-level debug/status/API contour в buildermgr, router или executor.
|
||
3. Выбрать один самый безопасный read-only endpoint или status surface.
|
||
4. Протащить наружу `NamespaceManagerSummary` без изменения watcher semantics.
|
||
5. Добавить unit/integration tests именно на внешний consumer-side path.
|
||
6. Документировать каждый шаг в новых файлах в `doc/thinking/`.
|
||
|
||
## Чего НЕ надо делать
|
||
|
||
1. Не продолжать внутреннюю консолидацию watcher layer ради самой консолидации.
|
||
2. Не ломать существующий runtime flow add/resync/remove.
|
||
3. Не вводить второй независимый источник правды о namespace state.
|
||
4. Не менять старые doc-файлы — только новые файлы с новыми шагами.
|
||
|
||
## Важные файлы для продолжения
|
||
|
||
- `pkg/utils/namespace_manager.go`
|
||
- `pkg/utils/namespace_manager_model.go`
|
||
- `pkg/utils/namespace_manager_test.go`
|
||
- `pkg/buildermgr/ns_watcher.go`
|
||
- `pkg/router/ns_watcher.go`
|
||
- `pkg/executor/multitenant/ns_watcher.go`
|
||
|
||
## Как начать с другого компьютера
|
||
|
||
Если работа продолжается в том же репозитории на той же VM, достаточно открыть репозиторий и проверить ветку:
|
||
|
||
`cd ~/terra/fission-src && git branch --show-current && git log --oneline -8`
|
||
|
||
Если ветка не выбрана, переключиться на неё:
|
||
|
||
`git checkout rewrite/layer2-namespace-manager-api-step1`
|
||
|
||
Если новый чат работает через VS Code tools над sshfs mount, локальный путь будет соответствовать смонтированной папке, а команды всё равно нужно запускать через SSH на VM.
|
||
|
||
## Готовый текст для первого сообщения в новом чате
|
||
|
||
Ниже текст, который можно вставить почти без изменений:
|
||
|
||
"Продолжаем в repo `fission-src` на ветке `rewrite/layer2-namespace-manager-api-step1`. Layer1 завершён и закрыт commit-ом `63ce6ea`. Внутренний `NamespaceManager` layer готов, buildermgr/router/executor уже сидят на общих watcher helper-ах, summary/debug contract стабилизирован и целевой прогон `go test ./pkg/utils/... ./pkg/buildermgr/... ./pkg/router/... ./pkg/executor/multitenant` уже был зелёным. Теперь нужен layer2: аккуратно найти лучший существующий read-only status/debug/API surface и начать вынос наружу `NamespaceManagerSummary` без изменения runtime semantics watcher-ов. Работай маленькими шагами, с новыми doc-файлами в `doc/thinking/`, без background команд, все команды только через SSH на VM и всегда с timeout."
|
||
|
||
## Ожидаемый первый технический шаг в новом чате
|
||
|
||
Не писать код сразу. Сначала найти реальный существующий endpoint или status surface, куда summary можно встроить безопасно и без архитектурного мусора. |