# Fission cron: наши выводы и факты

Короткий локальный конспект, чтобы не искать повторно по сторонней документации.

## Что делает оригинальный Fission

- Cron в Fission запускается штатным механизмом `TimeTrigger` / `timetrigger`.
- `timer` — отдельный controller-под, который живет постоянно, пока deployment поднят.
- `timer` смотрит только те namespace-ы, которые ему явно заданы при старте.
- Когда наступает время, `timer` инициирует обычный Fission invoke через `router`.
- Console не участвует в выполнении cron после создания/обновления `TimeTrigger`.

## Что важно для multi-namespace

- Да, в Fission изначально заложена работа с несколькими namespace-ами.
- Но это не "авто-перебор всего кластера".
- Нужен явный watch-list, обычно через `FISSION_RESOURCE_NAMESPACES`.
- Если namespace не входит в этот список, `timer` его `TimeTrigger` не увидит.

## Что делает наша console

- Console создает или обновляет `TimeTrigger` в namespace пользователя.
- В `TimeTrigger` задаются:
  - `spec.cron`
  - `spec.functionref`
  - `spec.method`
  - `spec.subpath`
- После этого дальнейший запуск полностью делает Fission.
- Console только управляет CRD и показывает состояние/метрики.

## Что мы выяснили в этом проекте

- Основная проблема была не в cron-механизме Fission как таковом, а в visibility namespaces для `timer`.
- `timer` сначала смотрел только `default`, поэтому user namespace был невидим.
- Дополнительно, history на `/cron` хранится в памяти процесса console, поэтому rollout сбрасывает накопленные снимки.

## Практический вывод

- Для cron важно не только создать `TimeTrigger`, но и убедиться, что `timer` watch-ит namespace пользователя.
- Если `/cron` пустой после rollout, это может быть:
  - `timer` не видит namespace
  - `TimeTrigger` не создан
  - invoke не дошел до функции
  - snapshot не сохранился в `cron_metrics`
- Console не запускает shell-команды в Kubernetes и не исполняет cron сама.
- Console только создает CRD, а дальше работает штатный Fission controller path.