Bug 47105

Summary:	Сервис выдачи номеров сборочных заданий для "догоняющих" сборочниц
Product:	Infrastructure	Reporter:	Anton Farygin <rider>
Component:	girar	Assignee:	placeholder <placeholder>
Status:	NEW ---	QA Contact:	Andrey Cherepanov <cas>
Severity:	enhancement
Priority:	P5	CC:	dshein, glebfm, iv, ldv, rider, sin
Version:	unspecified
Hardware:	x86_64
OS:	Linux

Description Anton Farygin 2023-08-03 08:15:06 MSK

Сейчас догоняющие сборочницы живут сами по себе и имеют собственную нумерацию сборочных заданий, что не даёт нам возможности в адекватном и удобном режиме добавить информацию о них на packages.altlinux.org или сделать публикацию результатов по аналогии с git.altlinux.org.
предлагаю добавить внутренний сервис, выдающий уникальные номера сборочных заданий для не-основной сборочницы. Это позвонит нам сделать сквозную нумерацию сборочных заданий для всех догоняющих сборочниц и забирать с них AMQP сообщения о статусах, загружать информацию о собранных пакетов и в целом добавить интерфейс по работе с заданиями.

Comment 1 Ivan A. Melnikov 2023-08-03 08:45:19 MSK

> [...] не даёт нам возможности в адекватном и удобном режиме добавить информацию о них на packages.altlinux.org [...]

По моему, таких возможностей немало: добавьте номерам задач префиксы при импорте в rdb например.

> забирать с них AMQP сообщения о статусах,

Не считаю это нужным для поддерживаемых мной портов.

Comment 2 Anton Farygin 2023-08-03 11:14:22 MSK

префикс к сожалению сильно усложняет архитектуру.

Comment 3 Ivan A. Melnikov 2023-08-03 12:36:10 MSK

(In reply to Anton Farygin from comment #2)
> префикс к сожалению сильно усложняет архитектуру.

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

Comment 4 Evgeny Sinelnikov 2023-08-03 13:17:00 MSK

(Ответ для Ivan A. Melnikov на комментарий #3)
> (In reply to Anton Farygin from comment #2)
> > префикс к сожалению сильно усложняет архитектуру.
> 
> А отдельный сервис, выдающий номера, усложняет и без того непростую
> архитектуру girar'а, и превращает его в распределённую систему, а значит
> учит его новым, отсутсвующим сейчас способам тормозить и/или не работать.

+1

Я тоже самое хотел написать.

Comment 5 Anton Farygin 2023-08-04 15:47:00 MSK

(Ответ для Ivan A. Melnikov на комментарий #3)
> (In reply to Anton Farygin from comment #2)
> > префикс к сожалению сильно усложняет архитектуру.
> 
> А отдельный сервис, выдающий номера, усложняет и без того непростую
> архитектуру girar'а, и превращает его в распределённую систему, а значит
> учит его новым, отсутсвующим сейчас способам тормозить и/или не работать.

Да нет же, вообще ничего не усложняет. Всё что нужно от girar - это резервировать номер и не использовать его для своих заданий.
Откуда вы там увидели усложнения ?

Ну, т.е. это легко можно заменить по идее на task new и task rm, т.к. равнозначно по своей сути, но неудобно по факту.

Comment 6 Danil Shein 2023-11-28 15:51:20 MSK

Если уж надо реализовать прям срочно, то можно поднять инфраструктуру (ALTRepoDB + ALTRepo API + ALTRepo Front) отдельно для догоняющей архитектуры.
Интегрировать это в основной p.a.o вполне можно и редиректом на субдомены вида riscv64.packages.altlinux.org и т.п.

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

Comment 7 Anton Farygin 2023-11-28 16:12:20 MSK

Вообще мне больше нравится когда все эти пакеты лежат в одной базе. те же аналитические запросы для сравнения делаются намного проще.

CVE опять же легче искать, обрабатывать и выписывать бюллетени.