Re: Генерация pool-based репозиториев
Victor Wagner -> debian-russian@lists.debian.org @ Tue, 5 Mar 2019 07:27:45 +0300:
>> Есть еще чуть более хитрый вариант — 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?
Можно и по http. Скрипт, который реагирует на запрос "мне, пожалуйста,
актуальную строчку для sources.list для такого-то дистрибутива". Вот он
уже на раз сделает readlink.
>> отрезолвленным именем, где заведомо консистентный репозиторий, который
>> уже никогда не поменяется, можно работать.
> Это для отрелизенных пакетов я могу себе позволить хранить
> заведомо-консистентные репозитории на каждый момент времени. Если это
> делать по схеме rsnapshot-а, т.е. каждый пакет хранить один раз и
> держать на него десяток хардлинков из разных снапшотов.
> А если хранить репозитории вечно для всех промежуточных билдов,
> успевших собрать хотя бы один пакет (а ведь туда для консистентности
> придется копировать все остальные пакеты из старого репозитория)
> никакого storage не хватит.
Я не сказал "хранить вечно". Я сказал "никогда не поменяется". Но может
быть удален целиком. Хранится вечно только то, что отрелизено. И да,
хардлинки.
Или, если аккуратно обходиться с версиями, то можно pool просто общий
держать.
>> > Прикрутить туда осмысленную систему exclusive и shared блокировок
>> > при условии того, что задания крутятся на куче разных машин и в
>> > репозиторий ходят apt-ом весьма нетривиально.
>>
>> Любая система с блокировками содержит race condition :) Один мутекс
>> еще нет, а любая система уже да.
> Ну, слава богу, в конторе, которая занимается разработкой СУБД, люди,
> способные грамотно спроектировать систему блокировок - найдутся.
>
> В принципе, одного мутекса НА КАЖДЫЙ РЕПОЗИТОРИЙ (например, все дебианы
> это один репозиторий, все убунты - другой, а каждая астра - отдельный)
> тут хватит.
> Основная проблема - гарантировать то, что при любых сбоях сборочного
> задания, в том числе и при ошибке установки пакетов-зависимостей,
> блокировка будет снята.
Во-во.
> Вообще говоря, для практических целей можно было бы обойтись
> троекратной попыткой повтора пары apt-get update/apt-get install
> с задержкой. Вероятность того что задание при этом обломится и
> потребует ручного перезапуска упадет до практически приемлемой.
... или так.
Reply to: