From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: To: devel@lists.altlinux.org References: <20191014205429.GB4322@altlinux.org> <20191014215312.GA1422683@portlab> <389be035-2465-8c54-5cb3-93eadbc94267@basealt.ru> <20191015061954.GA2061077@portlab> <20191015073206.GH18867@imap.altlinux.org> <194fdb47-10a6-42d1-467c-f6ddd77b6638@basealt.ru> <20191015182212.GB19142@altlinux.org> <867a7ee0-e7a2-b370-d393-6bf3361be1df@basealt.ru> <20191015183330.GC19142@altlinux.org> <480f7be6-e35a-e17b-6cc6-3ccee79e59bf@gmail.com> From: Anton Farygin X-Opacus-Archived: none Organization: BaseALT Message-ID: Date: Wed, 16 Oct 2019 07:56:11 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <480f7be6-e35a-e17b-6cc6-3ccee79e59bf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru Subject: Re: [devel] [I] rpm-build-vm: vm-run X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 04:56:11 -0000 Archived-At: List-Archive: List-Post: 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).