[devel] Задачи для сборочницы следующего поколения (was: Параллельная сборочница. Алгоритмы.)

[Dmitry V. Levin]

On Fri, Feb 16, 2018 at 12:33:20AM +0200, Igor Vlasenko wrote:
> Господа!
> 
> Вместо экстремистских призывов не выкладывать пакеты в Сизиф,

Попрошу воздержаться от развешивания ярлыков.

Очевидно, что публиковать якобы новые сборки пакетов, в которых
ничего не меняется, не просто не нужно, но и вредно.

Слепо пересобирать чужие сборки из-за записи в %changelog'е вида
- Rebuilt for https://fedoraproject.org/wiki/Fedora_NN_Mass_Rebuild
не просто не нужно, но и вредно.

> предлагаю все же обратить внимание на сборочницу.
> 
> Сборочница и сейчас тормозит, а с учетом
> скорого включения arm ее скорость еще упадет.

girar разрабатывался лет 9 назад для решения задач, которые были тогда
актуальны, на том оборудовании, которое было доступно в то время.

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

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

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

Вряд ли мы хотим решать задачу принимать в Сизиф 60*60*24/2==43200
транзакций в сутки (в среднем по 2 секунды на транзакцию), это число
более чем в 2 раза превышает число исходных пакетов в нынешнем Сизифе.
Такая задача сама по себе не выглядит осмысленной.

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

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

Нам нужен инструмент оперативного создания новых бранчей под разные задачи,
см. напр. https://bugzilla.altlinux.org/show_bug.cgi?id=23935

Нам нужен инструмент создания и обслуживания репозиториев-дополнений
к базовым репозиториям, включая автоматическую пересборку дополнений
по мере обновления базовых репозиториев,
см. напр. https://bugzilla.altlinux.org/show_bug.cgi?id=23936

Далее несколько комментариев про оборудование и алгоритмы применения
транзакций.

[...]
> Сейчас в процессорах ядер как грязи.

Не стоит преувеличивать.  В более-менее доступных серверных процессорах,
работающих на более-менее разумных частотах, сейчас около 32 ядер на
сервер (если не считать ht).

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

> Как это использовать?
> Чтобы не создавать пробку для ПСБП, мерж тоже нужно
> делать параллельно.
> Другими словами, не интегрировать из очереди на мерж
> по одной транзакции,
> а объединять все транзакции, накопившиеся к этому времени в очереди на
> мерж, в одну мега-транзакцию, которую и пытаться интегрировать.
> Дополнительная сложность здесь в алгоритме обработке ситуации, когда
> мерж мега-транзакции не удался, но там тоже ничего заумного (см. далее).

Наша традиционная сборочная система обладает следующим полезным свойством:
каждое следующее состояние репозитория получается в результате применения
транзакции к предыдущему состоянию.

Такой детерминизм позволяет воспроизводимо получать новое состояние
репозитория из старого путём последовательного применения транзакций.

Это свойство полезно для реализации вторичных догоняющих сборочных систем
для медленных архитектур.

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


-- 
ldv
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : signature.asc
Тип     : application/pgp-signature
Размер  : 801 байтов
Описание: отсутствует
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20180216/c4b36859/attachment-0001.bin>