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

[Anton Farygin]

On 16.10.2019 2:41, Leonid Krivoshein wrote:
>
>
> 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. Не 
> для всех архитектур пока, правда.

Такая автоматизация вне сборочницы уже есть и в целом работает.

Вопрос в том, что бы сделать её работу доступной для всех сборочных 
заданий и разработчиков. С публичными отчётами и логами о тестировании. 
Появление vm-run делает её в принципе возможной.

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

Сложные стенды вообще тяжело строить унифицированными инструментами. 
Часто так случается, что для сложных стендов наши инструменты в принципе 
не существуют (простой пример - стенд, одна из составляющих которых 
работает под Windows).