[make-initrd] udhcpc script в фиче network

Thu Sep 23 05:40:10 MSK 2021

23.09.2021 3:45, Alexey Gladkov пишет:
> On Thu, Sep 23, 2021 at 01:06:33AM +0300, Leonid Krivoshein wrote:
>>> Ты где-то отдельно пишешь код
>> Код отправляю пока в Сизиф и в локальную гитовницу:
>>
>> git.altlinux.org/people/klark/packages/make-initrd-bootchain.git
> Это отдельный репозиторий, делать ревью коммитов непонятно как.
> git.alt/people это почти худшее место для обсуждения хода. Даже тарболл и
> патчи в рассылке лучше.
>
> Ты несколько раз говорил про него, но я просто не знаю, что с ним делать.
>
> Я уже понял, что этот репозиторий живёт своей жизнью и имеет свою историю
> изменений. Эта история безусловно важна и выкидывать её будет ошибкой. Но
> проблема в том, что я не представляю как это мерджить поскольку это даже
> как subtree сделать.

Это WiP, история и патчи там черновые, даже с опечатками. Нет смысла 
держаться за такое. Всё делалось исходя из намеченного плана.

> Моё предыдущее предложение сделать патчсет уже не актуально в данной
> ситуации. Я предполагал, что у тебя будет некая минимальная реализация, а
> остальное мы доработали бы в рабочем порядке. В этом случае все изменения
> бы ли бы рабочими и проходили обсуждение. Увы, это всё теперь невозможно.

Скажу честно, с момента написания черновика документации, все коммиты в 
m-i-b кода не сильно прибавили, изменения коснулись, в основном, 
исправления найденных ошибок и недочётов. Т.е. размер на момент 
публикации в Сизифе примерно таким и был. Для обсуждения предлагалась 
самая первая минимальная реализация без диалогов. Ты её сильно 
раскритиковал и тогда я сделал вторую, уже с диалогами, в виде 
монолитной фичи. А это третья реализация, модульная, она такой 
практически и была изначально. Я не предлагаю перетаскивать doc -- это 
совершено не готовая часть для разработчиков и тестировщиков, туда как 
раз ушла часть кода от исходно опубликованной версии, ещё из дерева 
удалена вторая реализация. Так что я как раз готовил проект к апстриму.

> Но ты выбрал иную стратегию. Ты разрабатываешь вещь в себе в отдельном
> репозитории. Это просто некое отдельное решение на основе make-initrd.

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

> Этот репозитории повторяет стратегию make-initrd-propagator, который
> как-то встраивался в make-initrd. И то и другое отдельно стоящие вещи в
> себе. Новый, правда, интегрирован с основным кодом лучше.

Я так понимаю, это всё из-за интеграции с network. Но посуди сам: 
pipeline и network, плюс ещё несколько новых фич, это и есть тот набор, 
что ты сделал на замену пропагатора, я лишь приделываю к этому диалоги и 
совместимость с нынешним stage2. Если что-то не так приделываю, можно же 
это предметно обсуждать. Да, я сначала думал делать полный или частичный 
форк фичи network, потому что были большие сомнения, что удастся с ней 
интегрироваться. Но это последнее, что нужно было altboot, чтобы быть 
больше похожим на propagator (по возможностям) и удалось обойтись без 
форка, в отличии от pipeline. Ты можешь сказать, чем плоха такая 
интеграция? 
http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918 
-- работает просто идеально.

>>> вместо того чтобы обсуждать и порциями добавлять.
>> Если бы работы по обсуждённому ранее плану были завершены, мне бы только и
>> оставалось, что добавлять порциями. Но к сожалению работы ещё много. Ты сам
>> настаивал, чтобы продукт был тщательно проверен до того, как он поедет в
>> апстрим. Находятся замечания, предложения, приходится их устранять и
>> учитывать. А из-за этого у меня откладывается работа по автоматизации
>> тестового стенда. Конечно лучше, чтобы в апстрим поехал безупречно
>> работающий продукт. Ты и сам уже можешь посмотреть код в Сизифе, пощупать
>> очередные регулярки с разными опциями и методами загрузки.
>>
>> Лично мне кажется, что ни один пакет у нас так пристально не проверялся,
>> попадая в обычные продукты. Но altboot -- важное звено в процессе загрузки и
>> моя задача учесть совместимость с уже сделанным в Альте за многие годы.
> Я начинаю думать, что уже лучше оставить всё как есть сейчас. Пусть
> make-initrd-bootchain остаётся отдельным репозиторием и пакетом.
>
> Когда в make-initrd будут появляться новые интерфейсы или фичи, то они
> будут начинать использоваться в make-initrd-bootchain. В том числе, когда
> какой-то функционал будет переползать в апстрим.
>
> Иначе я просто не представляю как всё уже написанное поддерживать.

Код bootchain-core + bootchain-getimage + bootchain-waitdev сопоставим с 
нынешним pipeline. Предлагаю поступить так: эти три я сделаю одним 
патчсетом. Главное, чтобы твои автотесты не забраковали, т.к. 
совместимость с pipeline там соблюдена. Остальное можно сделать как 
хочешь -- каждую фичу одним патчем, всё в пределах одного выпуска. Я 
соберу тестовое задание, мы его протестируем, а как поддерживать -- уже 
вопрос наживной. При локализации проблем в области bootchian/altboot 
просто добавлять меня в cc: багов. Благо bc_debug позволяет собрать 
нужную диагностику.

> [...]
>> Как раз я старался учесть возможность перехода в будущем на более правильные
>> концепции. Но сейчас и тебе надо принять, как данность, что пусть
>> "функционал пропагатора" с твоей точки зрения не идеален, лучше чтобы он был
>> внутри make-initrd
> Вот тут ты ошибаешься. Мне не нужно и тебе не советую принимать как
> данность, что нужно повторять поведение, которое написано в 2004. Это
> поведение чуть-чуть устарело.
>
> Кроме того, если тебе нужно поведение propagator, то он уже есть и незачем
> его переизобретать.

Выше озвучивались не просто общие слова -- у нас куча граблей и нет 
способа быстро перейти на make-initrd + pipeline с ними. Вот простейший 
пример, мы готовимся избавиться от isolinux для legacy/x86, но сколько 
это будет тянуться -- неизвестно. Он сам (его брэндинг) добавляет опции 
пропагатора в загрузку и на это приходится ориентироваться, так как если 
не работает, сразу баг.

>> и работал как 1/80 часть его рантайма, а не наоборот,
>> чтобы настоящий propagator полностью выкидывал и заменял собой все 100%
>> рантайма make-initrd.
> Признаюсь тебе: мне нет дела до propagator. Это древний кусок гов^W кода.
> Раньше он замечательно работал без make-initrd. Он делает всё сам и своими
> методами.
>
> Считаю ли я, что _функционал_ propagator может быть реализован на
> make-initrd ? Да.

Именно это и делает altboot.

> Считаю ли я, что поведение propagator нужно воспроизводить ? Нет.

В каком смысле? Я не копировал его повеление в точности. Но методы -- 
нужны, совместимость со stage2 -- нужна. Многое сделано лучше и 
модульно, это нельзя назвать 100% копией поведения. И всё делалось в 
пределах исходной концепции pipeline, код декомпозирован.

> Я считаю, что должна быть сохранена совместимость до определённой степени.
> Я не считаю, что нужна полная копия поведения. Для последнего у вас есть
> сам propagator.

Его уже начали капитально переделывать под новые реалии. Но без меня.

>> Можно и нужно обсуждать, как лучше сделать это, не
>> ломая совместимости, и учитывая потребности перехода на что-то более
>> правильное в перспективе.
> Ты сам себе противоречишь. Я должен принять, как данность функционал
> пропагатора и не ломая совместимости с кодом 17 летней (на самом деле
> большей) давности переходить на что-то более правильное.

Коду инсталлятора уже 17 лет? Пропагатор был его первой частью. У ОС 
Альт есть два варианта при выкидывании пропагатора -- жить без 
инсталлятора или найти новый. К обеим вариантам пока не готовы. 
Перелопачивать старый -- тоже пока нет ресурсов. Так что замена в 
make-initrd должна быть адекватной. Но кроме инсталлятора есть ещё 
загрузчики, сетевая установка (alterator-netinst), да ещё куча всего, 
плюс документация. Это всё нужно переделывать. Сейчас это нереально.

> И при этом ты пишешь, что не потянешь сопровождение. Другими словами жить
> с и переписывать эту "данность" с учётом совместимости буду я ? Отличная
> перспектива.

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

> А давайте сначала вы осознаете, что вам не нужен клон propagator и будете
> апстримить уже стазу более правильное ?

Мы осознавали, что нам без этого не обойтись с самого начала, это 
обсуждалось ещё после первой же пробной версии. Иначе нужно осознать, 
что выкинуть нам придётся очень много, что невозможно без адекватной замены.

> Потому что сейчас всё что, сказал выглядит не очень здорово. Выглядит так,
> что пропагатор переписанный разом на форк pipeline мне пытаются скинуть на
> поддержку.

Да, есть немного и такого дела. А как бы ты хотел? Я тебя прекрасно 
понимаю. Вчера собрались регулярки и не грузится RPi4, сразу ко мне 
вопрос. В результате altboot оказался не причём, но так мне хотя бы 
спокойнее будет, а тебе какая разница, 80 тыс. строк кода поддерживать 
или 86 тыс., ты же к такому уже привык!? :-)

>>> И я до сих пор не видел ни одного патча. Поэтому для
>>> меня каждая твоя проблема является большим сюрпризом.
>> Кажется, несколько попыток я уже делал, в частности, отдельно предлагал
>> bootchain-interactive.
> Патчей или PR так и не было.

Я собирал тестовые задания с патчами, приводил тут на них ссылки. Нет у 
меня на гитхабе аккаунта или я не очень понимаю в этой терминологии.

[...]
> Так это неправильно. Пользователь может такое хотеть. Да и дело не только
> в dhcp -> static. Нужно уметь расконфигурировать интерфейс.

Да, согласен, но до этого мы ещё дожили на данном этапе развития.

>> if [ ! -s /bin/network-sh-functions ]; then
> В 2.22.0-13-g78001064a я специально реализовал проверку фич о которой мы
> говорили.

Да, но я на 2.23 только сегодня первый раз собрал, у меня до этого более 
старая версия была. Понятно, что надо будет менять в коде всё, о чём 
говорили, если уже появилось в make-initrd.

>> А полная совместимость с пропагатором требует другого синтаксиса
> А зачем эта совместимость ? Ты пишешь про это как про аксиому.

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

> Я не хочу отвлекаться на кулстори, но когда мы с inger@ писали инсталлер,
> то как-то пережили отсутствие совместимости с mandrake. А тут внезапно
> появилось желание иметь совместимость с его частью.

Я тоже не люблю совместимость, хочется всё с нуля написать. Но порою это 
дольше.

>>> [...]
>>> Я с самого начала обсуждения диалогов говорил, что они должны быть сделаны
>>> на системном уровне, чтобы весь код был готов к изменению параметров, но
>>> почему-то меня не услышали.
>> Тебе видней, как это реализовать на системном уровне, разве кто-то будет
>> возражать! Я не так хорошо пока знаю архитектуру make-initrd, но предлагал
>> перетащить на верхний уровень bootchain-interactive
> Я не понял как ты предлагал это перетакивать. Скопировать код в другой
> репозиторий ?

п.7 здесь (самый конец):
https://lists.altlinux.org/pipermail/make-initrd/2021-August/000521.html

и первый ответ тут:
https://lists.altlinux.org/pipermail/make-initrd/2021-August/000525.html

я был уверен, что уже удалил то задание, но нет. :-)
так это и был патч для make-initrd с фичей interactive.

> [...]
>>>>>> Если удастся найти рабочий вариант с диалогами настройки сети "вдогонку", у
>>>>>> нас снимется много вопросов о том, как интегрировать bootchain/interactive с
>>>>>> уже имеющимися фичами make-initrd. Будет хороший пример, как это можно
>>>>>> сделать.
>> P.S.: Если хочешь, давай остановимся на версии 0.1.5-alt3 и начнём её
>> апстримить. Вот прямо сегодня! :-)
> Я уже высказался про это выше.

Всё это время я следовал договорённостям. Так что ты меня сильно удивил. 
Не веришь -- склонируй к себе версию 0.1.5-alt3, удали bootchain-doc, 
т.к. его не предлагаю пока апстримить, посчитай объём чем-нибудь типа 
du/wc, а затем обнули до initial commit и сравни с полученным. Ничего 
тут не увеличилось, я в этом уверен. 200 строк -- не та разница, из-за 
которой это становится неподъёмной ношей. Мы занимаемся просто 
причёсыванием и доводкой до абсолютно рабочего состояния.

-- 
Best regards,
Leonid Krivoshein.