38981 2020-09-22 16:05:04 +0300 MQ для сборочницы и сопутствующих сервисов 2021-06-21 01:56:07 +0300 1 1 2 Infrastructure Infrastructure girar unspecified x86_64 Linux NEW P5 enhancement --- 1 rider placeholder glebfm iv jenya ldv legion mcpain mike rider sotor viy cas oldest_to_newest 192748 0 rider 2020-09-22 16:05:04 +0300 Предлагаю обсудить вопрос доработки сборочницы таким образом, что бы все события, происходящие в ней могли инициировать процессы как в самой сборочнице, так и в сопутствующих системах (webery, repodb, bugzilla, watch, repocop и тестирование пакетов в стабильные репозитории) Что хочется получить: возможность сопутствующим системам узнать о том, что в сборочной системе (и рядом стоящих сервисах) произошли какие-то изменение. Например: - добавлено/удалено задание - добавлено/удалено подзадание - задание стало разделяемым - изменилось описание (комментарий) к заданию) - заданию/подзаданию дали/отозвали approve/disapprove - статус задания изменился (FAILED/DONE/EPERM/PENDING/BUILDING и т.д.) - ACL пакета изменился - выложен репозиторий в публичное место (на наш ftp) т.е. - любое событие в сборочной системе, в факте появления которого могли бы быть заинтересованы внешние сервисы. Возможно, этот же механизм стоит использовать и для внутренних компонент сборочницы. Вопрос, на который пока нет ответа: какую систему использовать в качетстве MQ (я знаю только про rabbitmq), насколько она надёжная/кластеризуемая. Какие интерфейсы/API должны быть к ней (какие пожелания) для внешних сервисов. Насколько публичным должен быть интерфейс API ? 192749 1 rider 2020-09-22 16:07:23 +0300 Как происходит сейчас (по крайней мере в большинстве известных мне сервисов): или опрос по крону вплоть до ssh или отслеживание писем от girar Внутри сборочницы есть некий самописный MQ реализованный на файлах/каталогах. 192751 2 rider 2020-09-22 16:15:45 +0300 Возможно, у такой службы есть ещё потенциальные клиенты в виде догоняющих репозиториев, которым задания нужно выгребать по факту их выполнения в основной сборочнице. Но так же было бы неплохо от догоняющих репозиториев получать информацию для сопутствующих служб, например для систем автоматизации функций отдела тестирования или webery. Т.е. - по факту у нас сейчас работает не одна сборочница а несколько параллельных, но при этом только с основной сборочницы задания и репозитории отслеживаются внешними (для сборочницы) службами. наверное, стоит сразу предусмотреть возможность появления нескольких параллельно действующих сборочных систем, у каждой из которых может быть свои номера и состав сборочных заданий. 192768 3 iv 2020-09-23 08:19:21 +0300 (In reply to Anton Farygin from comment #1) > Как происходит сейчас (по крайней мере в большинстве известных мне сервисов): > или опрос по крону вплоть до ssh > или отслеживание писем от girar Для полноты картины упомяну, что робот, копирующий задания в mipsel-ную сборочницу по крону отслеживает $FROM_REPO/index/task.list.