Bug 47105

Summary: Сервис выдачи номеров сборочных заданий для "догоняющих" сборочниц
Product: Infrastructure Reporter: Anton Farygin <rider>
Component: girarAssignee: 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 опять же легче искать, обрабатывать и выписывать бюллетени.