Обсуждение стратегии перезагрузки ALTCOS при получении новой версии (коммита) ostree-репозитория)

[kafnevod]

При запуске операционной системы запускается сервис zincati который (примерно через 5-ти минутный интервал) отслеживает появление новых версий (коммитов) потока в рамках которых работает ALTCOS (altcos/x86_64/sisyphus, altcos/x86_64/p10, ...) на сайте http://altcos.altlinux.org

При появлении новой версии (коммита) zincati запускает процесс загрузки (deploy) новой версии и размещении ее в локальном репозитории.

После загрузки необходимо перезагрузить (reboot) систему (zincati поддерживает оперативную перезагрузку через kexec, которая пока не поддерживается в ALTCOS.

zincati поддерживает несколько стратегий перезагрузки:

• Immediate - немедленная (от 1 до 10 минут);
• Periodic - перезагрузка в указанные временные окна;
• Lock-based - перезагрузка с использованием единого координационного сервиса работающего по протоколу FleetLock

По умолчанию используется стратегия Immediate (немедленная)

Эта стратегия (как и стратегия Periodic) не очень удобна при наличии малого (возможно одного) числа серверов в ALTCOS кластере, так как перезагрузка системы может происходить вне котрол я системного администратора.

Возможно в этом случае желательна перезагрузка под контролем системного администратора.

В этой ситуации наиболее подходящая стратегия перезагрузки - Lock-based. Мы добавляем в систему сервис, работающий по протоколу FleetLock. В обычном режиме этот сервис блокирует перезагрузку. Системный администартор помотрев обновления, обнаружив их наличие и решив перезагрузить систему под своим контролем снимает блокировку. Система перезагружается под контролем системного администратора.

В дальнейшем (при реализации подветки altcos/.../k8s) эту стратегию можно будет перенести на координацию перезагрузки узлов k8s кластера через Kubernetes-based reboot-manager Typhoon

Другие средства управления перезагрузками

• если граф cincinatti возвращает для версии установленной у клиента org.fedoraproject.coreos.updates.deadend=true, то обновление данной ветки у клиента прекращается
• на стороне клиента может быть установлен параметр

[identity]
rollout_wariness = [0-1]

При значение 0 клиент получает последние обновления, при значении 1.0 (возможно) клиент обновлений не получает. При промежуточных значениях обновления задерживаются в зависимости от значения rollout_wariness. При установки этого значения при запросе графа версий потока оно передается серверу cincinnatti.
В настойщее время обработка этого параметра на стороне cincinatti-сервера не поддерживается.
Возможно стоит ее реализовать.

Ссылки

• Updates strategy
• FleetLock protocol
• fleetlock - reboot coordinator for Fedora CoreOS nodes in Kubernetes clusters
• Auto-updates