Bug 38981

Summary:	MQ для сборочницы и сопутствующих сервисов
Product:	Infrastructure	Reporter:	Anton Farygin <rider>
Component:	girar	Assignee:	placeholder <placeholder>
Status:	NEW ---	QA Contact:	Andrey Cherepanov <cas>
Severity:	enhancement
Priority:	P5	CC:	glebfm, iv, jenya, ldv, legion, mcpain, mike, rider, sotor, viy
Version:	unspecified
Hardware:	x86_64
OS:	Linux

Description Anton Farygin 2020-09-22 16:05:04 MSK

Предлагаю обсудить вопрос доработки сборочницы таким образом, что бы все события, происходящие в ней могли инициировать процессы как в самой сборочнице, так и в сопутствующих системах (webery, repodb, bugzilla, watch, repocop и тестирование пакетов в стабильные репозитории)

Что хочется получить:
возможность сопутствующим системам узнать о том, что в сборочной системе (и рядом стоящих сервисах) произошли какие-то изменение. Например:
- добавлено/удалено задание
- добавлено/удалено подзадание
- задание стало разделяемым
- изменилось описание (комментарий) к заданию)
- заданию/подзаданию дали/отозвали approve/disapprove
- статус задания изменился (FAILED/DONE/EPERM/PENDING/BUILDING и т.д.)
- ACL пакета изменился
- выложен репозиторий в публичное место (на наш ftp)

т.е. - любое событие в сборочной системе, в факте появления которого могли бы быть заинтересованы внешние сервисы.


Возможно, этот же механизм стоит использовать и для внутренних компонент сборочницы.

Вопрос, на который пока нет ответа: какую систему использовать в качетстве MQ (я знаю только про rabbitmq), насколько она надёжная/кластеризуемая. Какие интерфейсы/API должны быть к ней (какие пожелания) для внешних сервисов. Насколько публичным должен быть интерфейс API ?

Comment 1 Anton Farygin 2020-09-22 16:07:23 MSK

Как происходит сейчас (по крайней мере в большинстве известных мне сервисов):
или опрос по крону вплоть до ssh
или отслеживание писем от girar

Внутри сборочницы есть некий самописный MQ реализованный на файлах/каталогах.

Comment 2 Anton Farygin 2020-09-22 16:15:45 MSK

Возможно, у такой службы есть ещё потенциальные клиенты в виде догоняющих репозиториев, которым задания нужно выгребать по факту их выполнения в основной сборочнице.

Но так же было бы неплохо от догоняющих репозиториев получать информацию для сопутствующих служб, например для систем автоматизации функций отдела тестирования или webery. 

Т.е. - по факту у нас сейчас работает не одна сборочница а несколько параллельных, но при этом только с основной сборочницы задания и репозитории отслеживаются внешними (для сборочницы) службами.

наверное, стоит сразу предусмотреть возможность появления нескольких параллельно действующих сборочных систем, у каждой из которых может быть свои номера и состав сборочных заданий.

Comment 3 Ivan A. Melnikov 2020-09-23 08:19:21 MSK

(In reply to Anton Farygin from comment #1)
> Как происходит сейчас (по крайней мере в большинстве известных мне сервисов):
> или опрос по крону вплоть до ssh
> или отслеживание писем от girar

Для полноты картины упомяну, что робот, копирующий задания в mipsel-ную сборочницу по крону отслеживает $FROM_REPO/index/task.list.