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

This commit is contained in:
“Naeel”
2026-05-18 12:29:08 +04:00
parent c8ced44068
commit 650616b464
3 changed files with 38 additions and 23 deletions
+1 -1
View File
@@ -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"]
+1 -1
View File
@@ -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.
##
+36 -21
View File
@@ -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
2. Нарочно сломать ServiceAccount или RoleBinding (например, удалить SA или RB)
- kubectl delete sa fission-fetcher -n <tenant-ns>
3. Проверить, что NS уходит в фазу `failed` (видно в UI)
4. Через 30 сек NS должен автоматически восстановиться (phase → active)
- Проверить, что SA/RB пересозданы, функции снова работают
1. Открыть fission-console, создать tenant (новый managed namespace)
2. Нарочно сломать ServiceAccount или RoleBinding:
```bash
kubectl delete sa fission-fetcher -n <tenant-ns>
```
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)
2. Проверить, что:
- В managed NS нет orphaned pods (kubectl get pods -n <tenant-ns> — все pods с новым instanceID)
- Нет лишних cold start (функции стартуют быстро)
- В логах executor есть строки:
- PreRegisterManagedNamespaces
- adopt
- cleanup
1. Через fission-console вызвать несколько функций (чтобы были warm pods)
2. Рестартовать executor:
```bash
kubectl rollout restart deployment/executor -n fission
kubectl rollout status deployment/executor -n fission
```
3. Убедиться что:
- Функции продолжают работать без 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
```