Re: [devel] ресурсоёмкое тестирование пакетов

[Alexey Tourbin <at@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 5928 bytes --]

On Mon, May 18, 2009 at 02:24:47PM +0400, Victor B. Wagner wrote:
> On 2009.05.15 at 23:26:30 +0400, Alexey Tourbin wrote:
> 
> > Потому что такова семантика сборки заданий: они обладают семантикой
> > транзакции.  Если задание собрано успешно, то оно переводит репозитарий
> > в новое состояние, и сборка следующего задания начинается уже на новом
> > репозитарии.  Нельзя начинать собирать несколько заданий на старом
> > репозитарии и потом "сводить" несколько результатов сборки в один новый
> > репозитарий.  Это может закончиться очень плохо.
> 
> 1. Будет ли это "очень плохо" своевременно диагностировано?
> 2. С насколько высокой вероятностью это "очень плохо" может случиться?
> 
> А то может быть ждать десять раз по два часа плюс один раз - семнадцать
> (когда "очень плохо - случилось, и пришлось откатываться и строить все
> последовательно) будет несколько эффективнее, чем 11 раз по 15 часов?

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

"Сводить" несколько заданий на логическом уровне нельзя в любом случае.
Условия замещения пакетов могут быть слишком нетривиальными.  Мы ведь
допускаем произвольную перетасовку подпакетов между пакетами, а равно
и полное замещение пакетов по подпакету, и при этом ещё нужно уметь
проверять ACL (потому что существуют shared tasks, которые могут
формироваться разными людьми).  Корректно реализовать все эти процедуры
нам пока удалось только для схемы A->B, где A - старое/текущее состояние
репозитария, B - новое состояние репозитария.  Эта схема предполагает
явную сериализацию заданий.

> Вообще, с очевидность МОЖНО собирать несколько заданий на старом
> репозитарии и потом их сводить, при условии что эти задания от
> результатов друг друга абсолютно независимы.

Собирать можно, сводить нельзя. :)

> Понятно, что есть такие пакеты, от которых зависит практически все -
> filesystem, toolchain, базовые библиотеки. С ними почти ничего не
> запараллелишь. Но что мешает запараллелить, например, сборку
> какой-нибудь гномовской фигни со сборкой аналогичной kde-шной фигни?
> Или там сборку двух mail transfer agent-ов которые с точки зрения
> некоторых дистрибутивов принципиально не могут использоваться
> одновременно?

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

Когда мы начинаем собирать задание, мы исходим из того, что о пакетах
в этом задании нам ничего неизвестно.  Это моя принципиальная позиация,
если хотите.  У ldv на этот счет другая, но не принципиальная позиция.

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

B(S,C)->P

где
B -- процедура сборки пакета (build, hasher),
S -- исходный код пакета (src.rpm),
C -- содержимое сборочной среды (chroot),
P -- собранные пакеты.

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

Эта модель по сути уже реализована.  Когда задание завершается
с ошибкой, то в нём сохраняется информация о среде сборки.  При
возобновлении задания повторная пересборка некоторых пакетов может
не потребоваться.

Вот в каком виде эта информация представлена.
Рассмотрим задание 6670 с пакетом perl-Class-Accessor.

$ rsync -vaP git.altlinux.org::tasks/6670 $TMPDIR/tasks/
$ cd $TMPDIR/tasks/6670
$ find -name 'chroot_*'
./build/1/x86_64/chroot_base
./build/1/x86_64/chroot_BR
./build/1/i586/chroot_base
./build/1/i586/chroot_BR
$ head ./build/1/x86_64/chroot_base
SysVinit        2.86-alt2       x86_64  SysVinit-2.86-alt2.src.rpm      920f28e5ee12b122331eb5732964f0871a629eb7
alt-gpgkeys     0.7-alt2        x86_64  alt-gpgkeys-0.7-alt2.src.rpm    9f26e3268aabb7dad4d0860d663d66aa62171000
alternatives    0.4.1-alt2      noarch  alternatives-0.4.1-alt2.src.rpm 7d06d5c571995c00b4fa499c2636ab3868778266
autoconf-common 0.2-alt1        noarch  autoconf-common-0.2-alt1.src.rpm        bfe73e65a4471aae6c5be95520953502bc60d69f
autoconf_2.60   2:2.63-alt4     noarch  autoconf_2.60-2.63-alt4.src.rpm 4f4f3fc50d82a617e2cf184f4279622ec372bff8
automake-common 0.2-alt1        noarch  automake-common-0.2-alt1.src.rpm        1fb582eed4ecfd8a4d2db6ebd41ac7f2e4775c5e
automake_1.11   1.11-alt1       noarch  automake_1.11-1.11-alt1.src.rpm 73d43cb1b422e030bd6e08bd20a4997e788a0765
basesystem      1:sisyphus-alt17        noarch  basesystem-sisyphus-alt17.src.rpm       71126abe4f8918d6e34bc7a47cbf606e0420dae8
bash    3.2.39-alt2     x86_64  bash-3.2.39-alt2.src.rpm        b04ff27110379e289ba89e8213e9bbe2eeaaf3b9
binutils        1:2.19.51.0.2-alt1      x86_64  binutils-2.19.51.0.2-alt1.src.rpm       ced2379c393a4380f8088ff37e98aa28d48c1dcc
$ head ./build/1/x86_64/chroot_BR  
perl-devel      1:5.8.9-alt2    x86_64  perl-5.8.9-alt2.src.rpm 5b75802744adf0d9674451d251ee8125fc35b9b8
$ 

Здесь явно фиксируется среда C сборки пакета -- базовая часть сборочного
чрута (одинаковая для всех пакетов) плюс дополнительные пакеты, которые
являются замыканием BuildRequires.

В общем, модель есть, но реализовать на основе этой модели параллельную
сборку с сериализацией при сведЕнии -- это отдельная и достаточно
сложная задача.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]