fission-console/CRON/FISSION_CRON_NOTES.md

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.