47105 2023-08-03 08:15:06 +0300 Сервис выдачи номеров сборочных заданий для "догоняющих" сборочниц 2023-11-28 16:12:20 +0300 1 1 2 Infrastructure Infrastructure girar unspecified x86_64 Linux NEW P5 enhancement --- 1 rider placeholder dshein glebfm iv ldv rider sin cas oldest_to_newest 230792 0 rider 2023-08-03 08:15:06 +0300 Сейчас догоняющие сборочницы живут сами по себе и имеют собственную нумерацию сборочных заданий, что не даёт нам возможности в адекватном и удобном режиме добавить информацию о них на packages.altlinux.org или сделать публикацию результатов по аналогии с git.altlinux.org. предлагаю добавить внутренний сервис, выдающий уникальные номера сборочных заданий для не-основной сборочницы. Это позвонит нам сделать сквозную нумерацию сборочных заданий для всех догоняющих сборочниц и забирать с них AMQP сообщения о статусах, загружать информацию о собранных пакетов и в целом добавить интерфейс по работе с заданиями. 230793 1 iv 2023-08-03 08:45:19 +0300 > [...] не даёт нам возможности в адекватном и удобном режиме добавить информацию о них на packages.altlinux.org [...] По моему, таких возможностей немало: добавьте номерам задач префиксы при импорте в rdb например. > забирать с них AMQP сообщения о статусах, Не считаю это нужным для поддерживаемых мной портов. 230801 2 rider 2023-08-03 11:14:22 +0300 префикс к сожалению сильно усложняет архитектуру. 230807 3 iv 2023-08-03 12:36:10 +0300 (In reply to Anton Farygin from comment #2) > префикс к сожалению сильно усложняет архитектуру. А отдельный сервис, выдающий номера, усложняет и без того непростую архитектуру girar'а, и превращает его в распределённую систему, а значит учит его новым, отсутсвующим сейчас способам тормозить и/или не работать. 230808 4 sin 2023-08-03 13:17:00 +0300 (Ответ для Ivan A. Melnikov на комментарий #3) > (In reply to Anton Farygin from comment #2) > > префикс к сожалению сильно усложняет архитектуру. > > А отдельный сервис, выдающий номера, усложняет и без того непростую > архитектуру girar'а, и превращает его в распределённую систему, а значит > учит его новым, отсутсвующим сейчас способам тормозить и/или не работать. +1 Я тоже самое хотел написать. 230895 5 rider 2023-08-04 15:47:00 +0300 (Ответ для Ivan A. Melnikov на комментарий #3) > (In reply to Anton Farygin from comment #2) > > префикс к сожалению сильно усложняет архитектуру. > > А отдельный сервис, выдающий номера, усложняет и без того непростую > архитектуру girar'а, и превращает его в распределённую систему, а значит > учит его новым, отсутсвующим сейчас способам тормозить и/или не работать. Да нет же, вообще ничего не усложняет. Всё что нужно от girar - это резервировать номер и не использовать его для своих заданий. Откуда вы там увидели усложнения ? Ну, т.е. это легко можно заменить по идее на task new и task rm, т.к. равнозначно по своей сути, но неудобно по факту. 237964 6 dshein 2023-11-28 15:51:20 +0300 Если уж надо реализовать прям срочно, то можно поднять инфраструктуру (ALTRepoDB + ALTRepo API + ALTRepo Front) отдельно для догоняющей архитектуры. Интегрировать это в основной p.a.o вполне можно и редиректом на субдомены вида riscv64.packages.altlinux.org и т.п. На самом деле мы таким образом можем убрать вообще всю информацию о портах с основного сайта кроме ссылок, включая загрузку репозиториев портов, при этом получив одинаковый функционал для всех архитектур - как существующих, таки новых (если таковые появятся). 237967 7 rider 2023-11-28 16:12:20 +0300 Вообще мне больше нравится когда все эти пакеты лежат в одной базе. те же аналитические запросы для сравнения делаются намного проще. CVE опять же легче искать, обрабатывать и выписывать бюллетени.