[devel] I: git.alt update

[Alexey Tourbin]

On Mon, Nov 22, 2010 at 07:43:34PM +0300, Dmitry V. Levin wrote:
> > А какой принцип работы параллельной сборки?
> 
> girar-task-run поставляет задания в состоянии AWAITING;
> 
> N=3 экземпляра gb-toplevel-build выбирают задания в состоянии AWAITING,
> приоритет имеет задание с меньшим номером;
> 
> выбранное задание переводится в состояние BUILDING, и для него клонируется
> репозиторий;
> 
> для каждого аккаунта, зарегистрированного в системе, может быть не более
> одного задания в состоянии BUILDING;
> 
> собранные test-only задания переводятся в состояние TESTED,
> остальные собранные задания переводятся в состояние PENDING;
> 
> gb-toplevel-commit выбирает задания в состоянии PENDING c номером итерации
> не менее чем максимальный номер итерации всех заданий в состоянии
> BUILDING и PENDING для данного репозитория в данный момент времени,
> приоритет имеет задание с меньшим номером;
> 
> если репозиторий, для которого задание было собрано, отличается от
> репозитория, на котором оно было собрано, то задание переводится в в
> состояние AWAITING с увеличенным номером итерации;

То есть задание вступает в силу (коммитится), только если текущий
репозиторий равен клонированному репозиторию в задании?  Это хорошо.

С другой стороны, смотри.  Узнать, что репозиторий изменился (и что
придётся проигрывать всё задание заново) можно гораздо раньше, чем
в самом конце при попытке коммита задания.

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

lock_repo_for_reading,check_the_repo_is_unchanged,otherwise_fail_and_schedule_task_for_reiteration

Далее нарезать girar-builder, чтобы некоторые куски выполнялись под этим
локом, а некоторые - без него. Наример, gb-remote-build нужно разрезать на
две части: первая часть выполнятеся под локом, она готовит чрут для сборки
(в том числе выгребает пакеты из репозитория).  Вторая часть просто
собирает пакет - упрощенно говоря 'hsh-run rpmbuild ...', лок на
репозиторий для этого не нужен.

> задание переводится в состояние COMMITTING, репозиторий обновляется,
> и выполнение задания завершается.
> > Гарантируется ли строгая (логическая) сериализация заданий?
> А что это значит?

Это понятие из теории СУБД.  Транзакции могут выполняться параллельно,
но с точки зрения самой транзакции она выполняется как бы эксклюзивно,
а результат параллельного выполнения должен быть такой, как если бы
транзакции выполнялись в каком-либо порядке.  Иначе возникают неприятные
побочные эффекты (самый известный и простой - продать два билета на одно
место).

В girar-builder сериализация важна, потому что это единственный надёжный
способ контролировать целостность репозитория.  А именно, girar-builder
работает по следующему принципу: репозиторий переводится из текущего
состояния в (предполагаемое) новое состояние: A->A'.  Вычисляется некая
сложная характирестическая функция: H(A), H(A').  Далее принимается
решение, проходит контроль целостности или нет.

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

> > Например, параллельно собирались два задания - glibc и rpm,
> > и закончили собираться одновременно.  Как определить, сколько
> > и какие именно задания будут завершены?
> 
> По алгоритму, приведенному выше.

Т.е. одно коммитится, все остальные идут на реитерацию.