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 > с задержкой. Вероятность того что задание при этом обломится и > потребует ручного перезапуска упадет до практически приемлемой. ... или так.
