Bug 39276

Summary:	girar task run --limits [small\|normal(default)\|large] option
Product:	Infrastructure	Reporter:	viy <viy>
Component:	girar	Assignee:	placeholder <placeholder>
Status:	NEW ---	QA Contact:	Andrey Cherepanov <cas>
Severity:	enhancement
Priority:	P5	CC:	boyarsh, cas, ekorneechev, glebfm, lav, ldv
Version:	unspecified
Hardware:	x86_64
OS:	Linux
Bug Depends on:
Bug Blocks:	39324, 39328, 39614

Description

viy 2020-11-12 23:26:03 MSK

Еще раз всплыла проблема неадаптируемых лимитов сборочницы, о том, что пакеты разные и нет одного универсального лимита для всех пакетов
которая ранее встречалась редко и поэтому заметалась под ковер,
как, к примеру, в https://bugzilla.altlinux.org/show_bug.cgi?id=31683
(я тоже не особо страдал из-за отсутствия решения, так как в случае чего
удалял пакет из Сизифа и собирал в autoimports).

Но сейчас проблема всплыла в java. Я об ней писал в
https://lists.altlinux.org/pipermail/devel/2020-October/212079.html
После добавления armh noarch пакеты java должны пересобираться и на этой архитектуре, но сборка на armh и сама по себе у нас медленная,
и там умолчальной сейчас не-JIT JVM, что еще тормозит и выводит сборку за лимиты, соответственно, сборочница убивает задания раньше, чем они успели собраться.
Таких заданий уже скопилась небольшая очередь,
#259882 FAILED #1 sisyphus srpm=jruby-1.7.22-alt2_10jpp8.src.rpm
#259809 FAILED #2 sisyphus srpm=batik-1.11-alt1_3jpp8.src.rpm srpm=fop-2.4-alt1_1jpp8.src.rpm
#259709 FAILED #1 sisyphus srpm=jakarta-activation-1.2.2-alt1_1jpp9.src.rpm
#259499 FAILED #2 sisyphus srpm=jogl2-2.3.2-alt3_9jpp8.src.rpm
#259490 NEW #1 p9 srpm=java-10-openjdk-10.0.2.13-alt2_7jpp9.src.rpm
#259439 FAILED #2 sisyphus srpm=sbt-0.13.1-alt6_9.1jpp8.src.rpm
#259324 FAILED #1 sisyphus srpm=java-9-openjdk-9.0.4.11-alt4_6jpp8.src.rpm
#257261 FAILED #2 p9 srpm=java-9-openjdk-9.0.4.11-alt2_6jpp8.M90P.1.src.rpm

С этой статистикой можно оценить число пострадавших пактов в Сизифе в 30-120 шт.

Предлагаю, как самый ленивый вариант, ввести набор опций для управления лимитами, к примеру, wlimit_time_elapsed => --limit-time-elapsed large
с дискретным набором значений (normal=0/large=1 или normal(default)=0/small=1/large=2)
и примитивной реализацией:

сгенерировать на сборочных массив псевдопользователей с разными лимитами
и вычислять нужный номер псевдопользователя по опциям нужный номер псевдопользователя.
No=No-as-before+(Total pseudousers before)*(limit-time-elapsed)+(Total before)^2*(limit-time-idle)+ ... (Total before)^N*(limit-N)

Упрощая - завести в hasher-priv каждого сборочного узла еще 2 псевдопользователя
с номерами +100 и +200
к примеру normal -- обычный номер hasher (к примеру, 0),
small - номер hasher +100
large - номер hasher +200
и таким образом при сборке выбирать номер с нужным лимитом.

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

Comment 1

Dmitry V. Levin 2020-11-20 18:42:19 MSK

Все такие изменения быстро не делаются.

Comment 2

viy 2020-11-20 22:02:53 MSK

(Ответ для Dmitry V. Levin на комментарий #1)
> Все такие изменения быстро не делаются.

я думаю, что пара месяцев в запасе есть.

Comment 3

viy 2021-01-18 05:17:44 MSK

С time-idle limit мне помог хак от zerg' - добавить в спек 
(while true; do date; sleep 7m; done) &
который, хоть и безобразное решение, но позволяет обходить лимиты сборочницы.
а вот с wlimit_time_elapsed там все глухо,
так что проблема по прежнему серьезная.
в частности, по wlimit_time_elapsed не собирается бутстрапный jvm 9 в p9.
А он нужен и сам по себе, и чтобы ним собрать jvm 10 которым собрать jvm 11.

Comment 4

Andrey Cherepanov 2021-01-18 09:31:56 MSK

(Ответ для viy на комментарий #2)
> (Ответ для Dmitry V. Levin на комментарий #1)
> > Все такие изменения быстро не делаются.
> 
> я думаю, что пара месяцев в запасе есть.

Пара месяцев прошла. Дима, мы из-за отсутствия openjdk-11 не можем использовать в p9 javafx для сторонних приложений.

Comment 5

Dmitry V. Levin 2021-01-18 12:17:29 MSK

(In reply to Andrey Cherepanov from comment #4)
> (Ответ для viy на комментарий #2)
> > (Ответ для Dmitry V. Levin на комментарий #1)
> > > Все такие изменения быстро не делаются.
> > 
> > я думаю, что пара месяцев в запасе есть.
> 
> Пара месяцев прошла. Дима, мы из-за отсутствия openjdk-11 не можем
> использовать в p9 javafx для сторонних приложений.

Мне кажется, что ваши усилия направлены по неправильному адресу.

Comment 6

Dmitry V. Levin 2021-02-06 19:32:53 MSK

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