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

Thu Sep 23 14:38:14 MSK 2021

On Thu, Sep 23, 2021 at 05:40:10AM +0300, Leonid Krivoshein wrote:
> > Этот репозитории повторяет стратегию 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
> -- работает просто идеально.

К вопросу о ревью: вот и как предполагается комментировать код с git.alt ?
Ок, буду по ссылкам.

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#l12

Про это я уже писал. Это проверяется не так.

Остальной интегрируется так, что не использует ничего из того с чем
интегрируется.

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#l32

В network-sh-functions есть ipv4_enabled.

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#l51

Теряются абсолютно все ошибки. Ошибки в ip=, в macaddr, в указании масок.
Вместо всего этого будет "can't reconfigure network settings". Этого быть
не должно.

Также я уже говорил, что я думаю про дёргание /lib/initrd/cmdline.d/network.

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#l56

Этот шаг можно выполнить лишь один раз. Это не вяжется у меня с

"Can't bridge up network interface. Try with other network settings, wired
connection and/or cable."

Если пользователь попробует тот же интерфейс с другими настройками, то
второй раз проверки не будет ???

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#l65

Хардкод имени интерфейса. is_loopback().

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#l67

Для чего эта проверка ?

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#l73

Я полагаю это проверка на то что интерфейс поднят ? Если да, то is_link_up
Если проверка на присутствие адреса, то "/.initrd/online/$NET_IF".

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

Я уж не знаю вашей кухни, но вообще-то, да, это сразу бага.
Бага на брэндинг. Он передаёт устаревшие параметры.

Новый make-initrd+bootchain всё равно требует либо дополнительных, либо
других параметров для включения новых фич.

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

Если ты не копируешь повеление в точности, то пожалуйста поясни свой
тезис:

> Но сейчас и тебе надо принять, как данность, что пусть
> "функционал пропагатора" с твоей точки зрения не идеален, лучше чтобы он был
> внутри make-initrd

Если ты не занимаешься копированием, то неправильного "функционала
пропагатора" в новом коде быть не должно.

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

http://git.altlinux.org/gears/p/propagator.git?p=propagator.git;a=commitdiff;h=08639c8fafa30e0f78d19f1c5831fd2b1cc2bc02

Это, кстати, интересно.

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

Ваш _инсталлятор_ был написан для Server 4 (который был ещё до branch4).
Этот инсталлер, как и предыдущий использовал propagator как stage1. Так
что вашему инсталлеру уже примерно 11-12 лет, а propagator же был за долго
до него.

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

Не все модули, которые пишутся для make-initrd автоматически становятся
моими. Некоторые так и не попадают в репозиторий.

Всё что я принимаю в репозиторий я понимаю и поддерживаю. Я должен
понимать код и как он работает именно потому что он переходит от коммитера
в репозиторий.

> Не, ну давай будем поддерживать всем миром. ))

Именно потому что ты ставишь здесь смайлики я и не принимаю просто
"написанный код".

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

Обычно так и происходит. Коммитер пишет код, тестирует, документирует его,
отдаёт в апстрим и идёт своей дорогой. Но так происходит лишь тогда, когда
апстрим понимает и согласен со всеми предложенными изменениями.

То что ты написал не подпадает под последнее. У меня есть много вопросов
как архитектуре фич, так и к реализации. Когда ты решишь разрешишь все эти
вопросы, тогда я заберу код, а ты, если хочешь, можешь не участвовать в
его дальнейшей судьбе.

> Но я могу помогать с поддержкой, по возможности, хотя слабо представляю,
> как это возможно, когда это войдёт в состав make-initrd.

После вхождения изменений в мой репозиторий я не требую от тебя какой-то
поддержки. Но такое возможно лишь при разрешении всех моих вопросов.

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

Так вот оно что.

То есть ты просто единовременно переписал propagator на шелле, а не на
make-initrd, потому что твой код использует остальной мой код по
минимуму, получил make-initrd-propagator, но теперь с банановым вкусом и
хочешь, чтобы уже с новым неподдерживаемым кодом возился я (ты сам
пишешь, что не тянешь его поддержку).

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

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

Леонид, я не сотрудник, который работает с тобой. У меня нет возможности
анализировать тестовые задания и патчи в них.

Патчи можно слать по почте в рассылку или лично, можно завести аккаунт на
github и делать PR там, как это делает Пётр Михалицын.

Ещё раз для ясности: Я не готов лазать по каким-то там тестовым заданиям,
пакетам в сизифе с целью "а что бы такого ещё запстримить". Мне это не
нужно.

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

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

> > Я не понял как ты предлагал это перетакивать. Скопировать код в другой
> > репозиторий ?
> 
> п.7 здесь (самый конец):
> https://lists.altlinux.org/pipermail/make-initrd/2021-August/000521.html

Ок. Давай процитирую:

> > 6. Будешь ли ты сам ревьювить полностью отлаженный код до начала
> > процесса
> > апстрима или тебе лучше делать это по ходу?
> 
> Мне удобнее по ходу так как если вдруг возникнут вопросы, то править будет
> удобнее.

Мне удобнее по ходу. По ходу!!! Ты хоть куда-нибудь патчи посылал для
обсуждения ? В рассылке их нет. В личке тоже.

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

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

> и первый ответ тут:
> https://lists.altlinux.org/pipermail/make-initrd/2021-August/000525.html
> 
> я был уверен, что уже удалил то задание, но нет. :-)
> так это и был патч для make-initrd с фичей interactive.

Блин, опять какое-то тестовое задание, где нужно искать, что ты там
наменял. Я даже ссылку на строчку в diff с которой не согласен не могу
прислать сюда. Ещё бы через DHL распечатки кода прислали.

Знаешь, что мне такие "коммиты" даром не нужны. Далее обсуждать такой
подход добавления изменений в make-initrd не имеет смысла.

Если захочешь узнать как это делается без издевательства на ревьювером, то
спроси у Глеба или Димы.

-- 
Rgrds, legion