From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 23 Nov 2010 02:11:02 +0300 From: Alexey Tourbin To: ALT Devel discussion list Message-ID: <20101122231102.GB26538@altlinux.org> References: <20101027065747.GA18226@altlinux.org> <20101103061456.GA22511@altlinux.org> <20101122071209.GC22001@altlinux.org> <20101122164334.GA1787@altlinux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20101122164334.GA1787@altlinux.org> Subject: Re: [devel] I: git.alt update X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 23:11:03 -0000 Archived-At: List-Archive: List-Post: 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, > > и закончили собираться одновременно. Как определить, сколько > > и какие именно задания будут завершены? > > По алгоритму, приведенному выше. Т.е. одно коммитится, все остальные идут на реитерацию.