Re: [make-initrd] bootchain+altboot: у меня есть план

[Leonid Krivoshein <klark.devel@gmail.com>]

23.08.2021 12:29, Alexey Gladkov пишет:
> On Sat, Aug 21, 2021 at 10:14:22PM +0300, Leonid Krivoshein wrote:
>> Алексей, привет!
>>
>>
>> Почти два месяца, включая срочный проект и отпуск в полном ауте, но уже
>> вернулся к bootchain+altboot...
>>
>>
>> Оставшиеся у меня задачи:
>> =========================
>>
>> 1. Разобраться, как запускать виртуалку с -novga (без TTY's) и поработать в
>> консоли с dialog.
> Говорю просто для информации. В master переехала фича bootloader с TUI на
> libnewt. Правда он не модульный. Я слышал, что Петр Михалицын имеет
> некоторые мысли по развитию этого TUI.

Больше фич хороших и разных! Надо будет потом посмотреть.

Насчёт именно libnewt, помню, у коллег были большие сомнения. К слову, и 
propagator написан с зависимостями на неё.


>> 2. Добавить в bootchain-core и bootchain-intractive код для поддержки
>> netconsole.
> Не стоит ли сделать поддержку netconsole глобальной ?

Вчера уже выгрузил этот код, вроде всё работает. Основное попало в 
bootchain-interactive (bootchain-sh-functions и чуток в виджеты). Именно 
его с поддержкой netconsole имеет смысл делать отдельной фичей, как 
только её лучше назвать? В bootchain-core (форк pipeline) попало лишь 
крошечное изменение, теперь демон понимает опцию nottys, чтобы не 
создавать на tty3 процесс вывода журнала, это параметр из 
bootchain-interactive.

С этой netconsole наловил кучу дистрибутивных багов, не связанных с 
make-initrd. Не все умеют с ней работать, даже grub работает лишь в 
определённых условиях, в зависимости от образа. Нужно сначала понять, то 
ли я вообще сделал, что требовалось? Мне не удалось найти надёжного 
способа автоматического определения netconsole, поэтому пришлось ввести 
ещё один параметр nottys. Но вообще реализация получилась очень простой 
и, на первый взгляд, рабочей, и даже код определения размеров консоли 
пришёлся кстати. :-)


>> 3. Подготовить систему автоматизации развёртывания сервера сетевой загрузки
>> и установки.
>> 4. Добавить README по каждой фиче bootchain.
>> 5. Выполнить финальное тестирование всех возможных кейсов и
>> задокументировать этот процесс.
>> 6. Отлаженный пакет отправить в Сизиф, попросить Антона Мидюкова собирать
>> регулярки с bootchain.
>> 7. Согласовать с тобой оставшиеся вопросы по процессу апстрима в
>> make-initrd.
>> 8. Заапстримить новые фичи в make-initrd до выпуска продуктов на p10
>> (2021/10).
>> 9. Обсудить разногласия и замечания по документации.
>>
>> Уже работаю по этому плану!
> Я считаю, что план должен быть удобным тебе. Мне сложно приоритезировать
> работу, которую я не видел :) Ты автор, тебе и представлять работу.

Решаю задачу с автоматизацией тестирования в полу-ручном режиме и 
формализацией этого процесса. Осталось не так уж много. Разворачивать 
стенд полностью вручную и вспоминать на память все тест-кейсы каждый раз 
было бы неправильно. Но и закрыть проблему через какой-нибудь CI я сходу 
не смогу, не имел с этим опыта пока.

Если не считать последней формальной проверки и недостатка переведённых 
README, весь код уже готов, я считаю.


>> Вопросы для согласования плана по апстриму bootchain:
>> =====================================================
>>
>> 1. Будем перетаскивать bootchain-interactive в первую очередь отдельно от
>> остального и под каким именем? См.:
>> https://lists.altlinux.org/pipermail/make-initrd/2021-June/000454.html
> Возможность доспросить у пользователя что-нибудь давно назрела. Было бы
> здорово иметь её для всех модулей.

Нужно переименовать, чтобы не было ассоциации с bootchain. Только во 
что? early-dialog? im? interactive? interactive-mode? ...


>> 2. Будем сначала решать проблему обеспечения полной совместимости с
>> pipeline? См.:
>> https://lists.altlinux.org/pipermail/make-initrd/2021-July/000500.html
> Мне уже двое пользователей сказали о том, что используют pipeline. Я
> считаю, что держать два почти одинаковых модуля не имеет смысла тем более,
> что один вырос из другого.

Вчера я нашёл свою ошибку и у меня всё заработало с altboot даже так: 
root=pipeline pipeline=fg,altboot, вопреки черновику документации! :-)


>> 3. Будем дожидаться поддержки в самом make-initrd функционала проверки фичи
>> или оставим это пока в bootchain? См.:
>> https://lists.altlinux.org/pipermail/make-initrd/2021-July/000474.html
> Это я сделаю в следующем релизе.

Отлично! Уже видел часть проделанной работы в новых коммитах.

Тогда я (после разговора с тобой) создал несколько тредов для обсуждения 
возможности переноса из bootchain-sh-functions части API на более 
верхний уровень make-initrd...


>> 4. Будем дожидаться появления в make-initrd API для проверки и сравнения
>> версии или оставим это пока в bootchain? См.:
>> https://lists.altlinux.org/pipermail/make-initrd/2021-July/000471.html
> Постой. Тот тред был о том, что в /etc/initrd-release попадала
> неправильная версия, что было исправлено. Ни о каком API для сравнения
> речи не было.
>
> Зачем такой API вообще нужен ?

Плохо то, что я начал не с него, хотя про API говорил тоже, но позже. 
Сейчас конкретной нужды нет. Но если поведение чего-либо в самом 
make-initrd меняется в зависимости от версии, то было бы здорово такой 
API иметь -- у всех библиотек подобное есть и make-initrd для фич 
предоставляет какой-то API. Но в первую очередь я интересовался 
переносом функции initrd_version() из bootchain-core, т.к. это уже 
второй "клиент", выводящий версию initramfs.


>> 5. Будем дожидаться переноса в make-initrd API для более глубокой отладки
>> или оставим это пока в bootchain? См.:
>> https://lists.altlinux.org/pipermail/make-initrd/2021-July/000476.html
> Это в некотором смысле с предложенной фичёй debug-tools:
>
> https://github.com/osboot/make-initrd/pull/15
>
> Правда она приносит gdb/strace, а не отладку в скрипты. Можно их
> объединить или же держать отдельно для разных уровней отладки.
>
>> 6. Будешь ли ты сам ревьювить полностью отлаженный код до начала процесса
>> апстрима или тебе лучше делать это по ходу?
> Мне удобнее по ходу так как если вдруг возникнут вопросы, то править будет
> удобнее.

OK.


>> 7. Предлагаю такую последовательность отправки коммитов:
>> bootchain-interactive, затем bootchain-core + bootchain-getimage +
>> bootchain-waitdev, затем замена фичи pipeline виртуальной зависимостью на
>> фичи bootchain-getimage и bootchain-waitdev, всё остальное (вся пачка
>> altboot), можно одним коммитом. Так пойдёт?
> Вполне.

Отлично! Будет смысл согласовать "окно" после финальной проверки всего 
комплекса. Привязка по времени к продуктам на p10 необязательна, так как 
для тестирования решения более широкими массами оно должно сначала 
попасть в Сизиф и тогда есть шанс наловить больше багов на регулярках. 
При переносе в make-initrd мне придётся параллельно удалять это из Сизифа.


-- 
Best regards,
Leonid Krivoshein.