Re: Генерация pool-based репозиториев
В Mon, 04 Mar 2019 23:10:10 +0300
Artem Chuprina <ran@lasgalen.net> пишет:
>
> Есть еще чуть более хитрый вариант — cp -al, rsync в копию, и потом
> _почти_ атомарная пара rename либо перевешивание симлинка (тоже
> _почти_ атомарное). Второе лучше (см. ниже).
Вот для этого у rsync есть --link-dest. Которым уже довольно давно
научился пользоваться rsnapshot. Поэтому создавать копию можно прямо
тем же rsync-ом в процессе. Правда, по-моему авторы всяких дебмирроров
об этом пока не задумывались.
>
> > Отдельное развлечение случается когда у тебя параллельно работает
> > десяток jenkins-овских заданий, собирающих разные пакеты, зависящие
> > друг от друга. Может запросто получиться так, что задание 1 сделало
> > apt-get update, потом задание 2 выложило новую версию своего
> > пакета и перергенерировало packages, а потом задание 1 захотело
> > этот пакет поставить, потому что он у него Build-Depends.
>
> В таком раскладе либо задание 2 не должно удалять старую версию пакета
> (а делать это должен кто-то третий в конце всего прогона или еще по
> какому-то критерию "старая версия больше никому не нужна"), либо у
> тебя неконсистентность прямо в постановке задачи.
>
> То, что задание 2 перегенерировало packages, само по себе для задания
> 1, которое уже сделало apt-get update, по барабану. Важно, чтобы пакет
> оставался.
В принципе, конечно да. Если бы поднимать версию пакета при каждом
билде, можно было бы действовать и так. Хотя сформулировать критерий
"эта версия пакета больше никому не нужна" крайне нетривиально.
Но в процессе отладки пакета его можно пересобрать и десять, и двадцать
раз, и в распределенной системе сборки он каждый раз должен попадать во
внутренний репозиторий, доступный для других заданий.
Поэтому у меня сейчас во внутреннем репозитории допустима замена пакета
без изменения его версии. А вот тут уже неатоммарность пары apt-get
update - apt-get install вылезает в полный рост.
> Другое дело, что race condition вида "у задания 1 прямо в процессе
> apt-get update могли оказаться Release и Packages разных версий
> репозитория" все равно остается.
>
> Чтобы его не было, см. выше про симлинк. Перед apt-get update делается
> readlink, прочитанное имя пишется в sources.list, и уже с этим
readlink по http?
> отрезолвленным именем, где заведомо консистентный репозиторий, который
> уже никогда не поменяется, можно работать.
Это для отрелизенных пакетов я могу себе позволить хранить
заведомо-консистентные репозитории на каждый момент времени. Если это
делать по схеме rsnapshot-а, т.е. каждый пакет хранить один раз и
держать на него десяток хардлинков из разных снапшотов.
А если хранить репозитории вечно для всех промежуточных билдов,
успевших собрать хотя бы один пакет (а ведь туда для консистентности
придется копировать все остальные пакеты из старого репозитория)
никакого storage не хватит.
У меня сейчас логи билдов всего лишь за год 700 гигов занимают.
А репозитории имеют объем примерно на порядок -два больше, чем логи.
> > Прикрутить туда осмысленную систему exclusive и shared блокировок
> > при условии того, что задания крутятся на куче разных машин и в
> > репозиторий ходят apt-ом весьма нетривиально.
>
> Любая система с блокировками содержит race condition :) Один мутекс
> еще нет, а любая система уже да.
Ну, слава богу, в конторе, которая занимается разработкой СУБД, люди,
способные грамотно спроектировать систему блокировок - найдутся.
В принципе, одного мутекса НА КАЖДЫЙ РЕПОЗИТОРИЙ (например, все дебианы
это один репозиторий, все убунты - другой, а каждая астра - отдельный)
тут хватит.
Основная проблема - гарантировать то, что при любых сбоях сборочного
задания, в том числе и при ошибке установки пакетов-зависимостей,
блокировка будет снята.
Вообще говоря, для практических целей можно было бы обойтись
троекратной попыткой повтора пары apt-get update/apt-get install
с задержкой. Вероятность того что задание при этом обломится и
потребует ручного перезапуска упадет до практически приемлемой.
--
Victor Wagner <vitus@wagner.pp.ru>
Reply to: