build: fix base image, bump to v1.22.1, update test plan

_build/linux_amd64/Dockerfile

@@ -1,3 +1,3 @@
-FROM cgr.dev/chainguard/static:latest@sha256:a301031ffd4ed67f35ca7fa6cf3dad9937b5fa47d7493955a18d9b4ca5412d1a
+FROM gcr.io/distroless/static-debian12:nonroot
 COPY fission-bundle /
 ENTRYPOINT ["/fission-bundle"]

charts/fission-all/values.yaml

@@ -25,7 +25,7 @@ image: fission/fission-bundle
 ## It is also used by the chart to identify version of the few more images apart from fission-bundle.
 ## Keep it empty for using latest tag.
 ##
-imageTag: v1.22.0
+imageTag: v1.22.1
 
 ## pullPolicy represents the pull policy to use for images in the chart.
 ##

doc/INTEGRATION_TEST_PLAN_P1_P2.md

@@ -3,45 +3,60 @@
 ## Контекст
 Ветка: `fix/namespace-lifecycle-hardening` (fission-src)
 Коммиты: P1 (auto-recovery failed NS), P2 (adopt orphaned pods)
+Образ executor: `naeel/fission-bundle:v1.22.1` (задеплоен 2026-05-18)
+Тестирование — через **fission-console** UI.
 
 ---
 
 ## 1. Проверка P1: auto-recovery failed NS
 
-1. Создать tenant (managed namespace) через fission-console UI
+1. Открыть fission-console, создать tenant (новый managed namespace)
-2. Нарочно сломать ServiceAccount или RoleBinding (например, удалить SA или RB)
+2. Нарочно сломать ServiceAccount или RoleBinding:
-   - kubectl delete sa fission-fetcher -n <tenant-ns>
+   ```bash
-3. Проверить, что NS уходит в фазу `failed` (видно в UI)
+   kubectl delete sa fission-fetcher -n <tenant-ns>
-4. Через 30 сек NS должен автоматически восстановиться (phase → active)
+   ```
-   - Проверить, что SA/RB пересозданы, функции снова работают
+3. В UI убедиться, что namespace ушёл в фазу `failed`
+4. Через ~30 сек namespace должен автоматически восстановиться (`active`)
+   - SA/RB пересозданы
+   - Функции снова работают (запустить любую тестовую функцию)
 
 ---
 
 ## 2. Проверка P2: adopt orphaned pods после рестарта executor
 
-1. Сделать rolling restart executor (kubectl rollout restart deployment fission-executor -n fission)
+1. Через fission-console вызвать несколько функций (чтобы были warm pods)
-2. Проверить, что:
+2. Рестартовать executor:
-   - В managed NS нет orphaned pods (kubectl get pods -n <tenant-ns> — все pods с новым instanceID)
+   ```bash
-   - Нет лишних cold start (функции стартуют быстро)
+   kubectl rollout restart deployment/executor -n fission
-   - В логах executor есть строки:
+   kubectl rollout status deployment/executor -n fission
-     - PreRegisterManagedNamespaces
+   ```
-     - adopt
+3. Убедиться что:
-     - cleanup
+   - Функции продолжают работать без cold start задержки
+   - В логах executor есть строки `PreRegisterManagedNamespaces`, `adopt`, `cleanup`:
+     ```bash
+     kubectl logs -n fission -l svc=executor --tail=100 | grep -E "PreRegister|adopt|cleanup"
+     ```
 
 ---
 
-## 3. Проверить отсутствие регрессий
+## 3. Проверить отсутствие регрессий (через fission-console)
 
 - Создание/удаление tenant работает
-- Функции запускаются, логи доступны
+- Функции создаются, редактируются, выполняются
-- Нет ошибок в UI/логе
+- Логи функций доступны в UI
+- Нет ошибок в UI и в логах executor/router
 
 ---
 
-## 4. (Опционально) e2e-скрипт
+## 4. Команды для диагностики
 
-- Автоматизировать сценарии выше bash-скриптом или через API fission-console
+```bash
+# Текущий образ executor
+kubectl get deployment executor -n fission -o jsonpath="{.spec.template.spec.containers[0].image}"
 
----
+# Логи executor (последние 200 строк)
+kubectl logs -n fission -l svc=executor --tail=200
 
-**Если нужна помощь с командами — пиши!**
+# Статус managed NS
+kubectl get ns -l managed-by=fission
+```