[devel] [I] rpm-build-vm: vm-run

[Leonid Krivoshein]

15.10.2019 21:48, Anton Farygin пишет:
> On 15.10.2019 21:33, Dmitry V. Levin wrote:
>> On Tue, Oct 15, 2019 at 09:28:09PM +0300, Anton Farygin wrote:
>>> On 15.10.2019 21:22, Dmitry V. Levin wrote:
>>>> On Tue, Oct 15, 2019 at 02:30:16PM +0300, Anton Farygin wrote:
>>>>> On 15.10.2019 10:32, Michael Shigorin wrote:
>>>>>> Зачем это тащить в hasher, особенно если на сборочнице?
>>>>>> Собрал тестовое задание, гоняешь по нему спокойно тесты.
>>>>> Есть цель сделать автоматическое тестирование воспроизводимым 
>>>>> образом и
>>>>> сразу в процессе сборки пакета.
>>>> Вопрос, что мешает поместить всё необходимое в сборочную среду?
>>>>
>>> Я не совсем понимаю механизм, с помощью которого я могу поместить всё
>>> необходимое в сборочную среду.
>> А что из себя представляет всё необходимое?
> Для того теста, который я хотел бы попробовать сделать - это 
> репозиторий apt, из которого собирался данный hasher root (или доступ 
> к этому репозиторию через apt).
>
> Грубо говоря - если мы хотим проверить инструментарий работы с 
> репозиторием (apt, packagekit) во время сборки полноценно, то 
> небольшого синтетического набора пакетов скорее всего будет 
> недостаточно и его надо проверять на всей  доступной пакетной базе.
>

Мне кажется, что сильно ограниченный чрут, коим является hasher, равно 
как и vm-run, для решения данной задачи не подходят. С qemu-виртуалками 
я без проблем пробрасываю /ALT внутрь через 9p. Как я понимаю, запрос не 
на фичу в vm-run -- она может пробросить через 9p из хэшера что угодно. 
Вопрос на предоставление /ALT/чего-то/там через механизм хэшера 
allowed_mountpoints на публичной сборочнице. Обычно в хэшере не нужен 
APT, поскольку он снаружи вместе со своим aptbox'ом. Но ничто не мешает 
положить ещё один APT внутрь. Наверное, для себя пропатчить hasher-priv 
можно, но будет ли такая фича полезна в публичной сборочнице -- вопрос к 
ldv@ и команде glebfm на .

По-моему, такую автоматизацию проще выполнять на виртуалках, а не в 
хэшере. При этом должен быть доступ ко всем состояниям репозитория. Для 
автоматизации сборки/изменения/наполнения виртуалки можно использовать 
мой autorun и полезную возможность qemu --no-reboot. Не для всех 
архитектур пока, правда.

В этой связи есть призыв (адресую всем, кто ведёт свои тайные 
разработки) -- максимально унифицировать механизмы взаимодействия с 
hasher, qemu, sudo-root a.k.a. tar2fs, потенциально возможными в степях 
obivalger@ и shaba@ аналогичными инструментами контейнеризации. Чтобы 
внутренние скрипты, выполняющие что-то полезное "как бы под рутом" 
внутри этой среды были не очень сильно зависимыми от того, кто и какую 
среду им смоделировал снаружи. А главное, чтобы в процессе моделирования 
можно было, в зависимости от архитектуры и задачи, определять более 
подходящий инструмент моделирования. Воспроизводимой сборки пакетов это, 
конечно, не касается, речь об автоматизации тестирования, сборки и 
перепаковки образов, моделирования сетевого взаимодействия, построения 
сложных стендов, итп.


-- 
Best regards,
Leonid Krivoshein.

----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20191016/9fe4f40c/attachment.html>