<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=KOI8-R">
</head>
<body text="#000000" bgcolor="#999999">
<br>
<br>
<div class="moz-cite-prefix">15.10.2019 21:48, Anton Farygin пишет:<br>
</div>
<blockquote type="cite"
cite="mid:d673c5fd-47b1-a547-e54d-04d6fbeaea59@basealt.ru">On
15.10.2019 21:33, Dmitry V. Levin wrote:
<br>
<blockquote type="cite">On Tue, Oct 15, 2019 at 09:28:09PM +0300,
Anton Farygin wrote:
<br>
<blockquote type="cite">On 15.10.2019 21:22, Dmitry V. Levin
wrote:
<br>
<blockquote type="cite">On Tue, Oct 15, 2019 at 02:30:16PM
+0300, Anton Farygin wrote:
<br>
<blockquote type="cite">On 15.10.2019 10:32, Michael
Shigorin wrote:
<br>
<blockquote type="cite">Зачем это тащить в hasher,
особенно если на сборочнице?
<br>
Собрал тестовое задание, гоняешь по нему спокойно тесты.
<br>
</blockquote>
Есть цель сделать автоматическое тестирование
воспроизводимым образом и
<br>
сразу в процессе сборки пакета.
<br>
</blockquote>
Вопрос, что мешает поместить всё необходимое в сборочную
среду?
<br>
<br>
</blockquote>
Я не совсем понимаю механизм, с помощью которого я могу
поместить всё
<br>
необходимое в сборочную среду.
<br>
</blockquote>
А что из себя представляет всё необходимое?
<br>
</blockquote>
Для того теста, который я хотел бы попробовать сделать - это
репозиторий apt, из которого собирался данный hasher root (или
доступ к этому репозиторию через apt).
<br>
<br>
Грубо говоря - если мы хотим проверить инструментарий работы с
репозиторием (apt, packagekit) во время сборки полноценно, то
небольшого синтетического набора пакетов скорее всего будет
недостаточно и его надо проверять на всей доступной пакетной
базе.
<br>
<br>
</blockquote>
<br>
Мне кажется, что сильно ограниченный чрут, коим является hasher,
равно как и vm-run, для решения данной задачи не подходят. С
qemu-виртуалками я без проблем пробрасываю /ALT внутрь через 9p. Как
я понимаю, запрос не на фичу в vm-run -- она может пробросить через
9p из хэшера что угодно. Вопрос на предоставление /ALT/чего-то/там
через механизм хэшера allowed_mountpoints на публичной сборочнице.
Обычно в хэшере не нужен APT, поскольку он снаружи вместе со своим
aptbox'ом. Но ничто не мешает положить ещё один APT внутрь.
Наверное, для себя пропатчить hasher-priv можно, но будет ли такая
фича полезна в публичной сборочнице -- вопрос к ldv@ и команде
glebfm@.<br>
<br>
По-моему, такую автоматизацию проще выполнять на виртуалках, а не в
хэшере. При этом должен быть доступ ко всем состояниям репозитория.
Для автоматизации сборки/изменения/наполнения виртуалки можно
использовать мой autorun и полезную возможность qemu --no-reboot. Не
для всех архитектур пока, правда.<br>
<br>
В этой связи есть призыв (адресую всем, кто ведёт свои тайные
разработки) -- максимально унифицировать механизмы взаимодействия с
hasher, qemu, sudo-root a.k.a. tar2fs, потенциально возможными в
степях obivalger@ и shaba@ аналогичными инструментами
контейнеризации. Чтобы внутренние скрипты, выполняющие что-то
полезное "как бы под рутом" внутри этой среды были не очень сильно
зависимыми от того, кто и какую среду им смоделировал снаружи. А
главное, чтобы в процессе моделирования можно было, в зависимости от
архитектуры и задачи, определять более подходящий инструмент
моделирования. Воспроизводимой сборки пакетов это, конечно, не
касается, речь об автоматизации тестирования, сборки и перепаковки
образов, моделирования сетевого взаимодействия, построения сложных
стендов, итп.<br>
<br>
<br>
<pre class="moz-signature" cols="72">--
Best regards,
Leonid Krivoshein.</pre>
</body>
</html>