[devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Igor Vlasenko]

Мухи и котлеты: Основная ошибка дизайна сборочницы.
___________________________________________________

Тема улучшения сборочницы почему-то пугает народ.
Что же это такое страшное и непонятное?

Попробую объяснить на пальцах.

Основная ошибка дизайна еще той, первой, последовательной
сборочницы была в том, что для и репозиториев, и для task'ов
использовался один и тот же ID.
ID репозитория можно увидеть через симлинк:
/ALT/repo/sisyphus/release/latest -> ../task/257002/
Удобная экономия на метаданных:
По одному ID можно определить, что репозиторий ID 257002
сделан из репозитория ID 257001 и task'а ID 257002.

Но task'и и репозитории --- это разные сущности.
Их смешивать --- это как смешивать мухи и котлеты.

Из-за смешения понятий в нашей сборочнице
появилось удивительное ограничение: на одну котлету
(репозиторий) может сесть только одна муха (task).

Другими словами, к каждому task'у жестко прибит
выпуск отдельного репозитория.

Это ограничение и не дало впоследствии переделать нашу
сборочницу в по настоящему параллельную.

Рассмотрим на примере.
Пусть человек1 ... человекN работали с утра
до обеда и перед уходом на обеденный перерыв
одновременно залили в Сизиф (репозиторий1500000)
пакет1... пакет256 в виде task'ов таск1500001...таск1500256
(порядок получился случайным)
со средним временем сборки task'а 5 минут.
Выпуск репозитория -- процесс не быстрый
(genbasedir c с кешем 10+секунд, потом mkaptbox, 10+секунд,
еще другие тесты. для простоты положим 0.5 минуты).

Во времена последовательной сборочницы эти task'и
выстроились бы в очереди, и окончания их сборки
пришлось бы ждать сутки (256*5.5, 23 с половиной часа).

С другой стороны, в параллельной сборочнице,
за которую я агитирую, каждый task собирался бы
параллельно на своем ядре, и на отдельном ядре
работал бы процесс выпуска репозитория,
который выпустил бы не 256 новых репозиториев,
а 5-10, пока task'и не кончились бы.
Среднее время ожидания выхода нового сизифа с task'ом --
5.5 минуты. Это хорошая иллюстрация,
зачем нужна производительная сборочница.
Сделал что-то и изменения почти сразу вступают в силу,
не нужно ждать до суток, как у последовательной сборочницы.

Разница всего лишь в параллельных алгоритмах --
железо используется на два порядка эффективнее.

Теперь вернемся к той сборочнице, которая есть сейчас.

На картинке
https://pbs.twimg.com/media/CPGh7UvUEAAcaAB.jpg:large
изображена основная проблема многопроцессорных кластеров --
однопоточные приложения. На картинке один поток работает
с лопатой в яме, а вокруг целая бригада потоков в режиме
ожидания его морально поддерживает.

Это хорошая иллюстрация к нашей сборочнице.
Ее можно описать моделью чайной. В ней работает 256 поваров,
которые заваривают чай со всеми тонкостями чайной церемонии.
Потребители --- огромное море-репозиторий туристов на
зимней морозной площади, которое выпьет
любое количество горячего чая.

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

Итак, как работает модель нашей сборочницы.

Поставщики человек1 ... человекN одновременно поставили в цех
пакет_чая1... пакет_чая256. Повар1 ... повар256 одновременно
начали чайную церемонию, проверили пакеты (негодные в FAILED)
через 5 минут заварили горячий чай и ... выстроились в очередь
(AVAITING 1.2) к парнишке-официанту!

Ведь по правилу "одна муха на одну котлету" официанту брать
более одного стакана на доставку запрещено, а путь к площади
не близкий!

Что делать поварам, когда их очередь не подошла?
Раньше они стояли с термометром и когда чай остынет, то
время от времени подогревали его заново (AVAITING 1.3, 1.4, 1.5, ...)
Помню, своими глазами видел AVAITING 1.27. AVAITING 1.3х? Не помню.
Но Дмитрий со временем навел порядок в этом безобразии.
Лишние печи для подогрева были проданы, и теперь ими
пользоваться могут лишь первые 6(?) поваров ближе всех
в очереди к официанту. Остальные повара просто стоят в очереди
без дела, держа свой остывающий чай.

Реформа параллелизма -- это выдать парнишке корзинку или тележку
на 16x16=256 стаканов, чтобы у поваров очередь просто не могла возникнуть.
Очевидная реформа, почему ее воспринимают в штыки?

Конечно, эта модель не точная.

Во первых, есть еще архитектуры, и на разных архитектурах
разное количество поваров.

Во вторых, в нашей сборочнице официант не выделен в отдельную
должность, и на самом деле бегает на площадь официантом тот
повар, которому пришла очередь. Это решение по ряду причин
хуже решения с явно выделенными официантами.
К примеру, сейчас на редких архитектурах повара, похоже,
тоже бегают официантами, а ведь их зарплата выше.
Если разделить процессы BUILD и MERGE, то выпуск репозитория
для всех, в т. ч. экзотических архитектур,
можно поручить более дешевым x86_64 узлам,
тем самым увеличив общую скорость работы по всем архитектурам.

В третьих, если собрать 256 стаканов на тележку,
то ее с малой вероятностью может заклинить пакетами,
нарушившими обратную совместимость. Поэтому одного официанта мало,
см. https://www.altlinux.org/Girar/Parallel,
для сохранения производительности можно, к примеру,
набрать Log2(256)=8 официантов, каждый копирует (магия software)
стаканы в свою конфигурацию,
к примеру, они берут 1 стакан, 2, 4, 8, 16, 32, 64, 128 и 256 стаканов,
и гарантированно хотя бы один донесет свою тележку.
В самом худшем случае будет производительность сегодняшней сборочницы,
но обычно будет на порядки быстрее.

Ранее я неудачно сравнил модернизацию сборочницы с постройкой шоссе.
потому что слово постройка вызвало реакцию лишними расходами.
К примеру Антон Фарыгин не принял аналогию -
AF> не надо строить <в сборочнице> хайвей.

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

Я не понимаю этого мазохизма. Деды часами таски ждали
и мы часами будем ждать?

Когда я начинал autoimports, то сборки обновлений тянулись сутками.
Сел за матчасть, распараллелил и оптимизировал сборочный процесс,
и теперь у меня сборка обновлений на тысячи пакетов занимает пол часа- час.

А наша сборочница меня просто раздражает своей медлительностью.
При чем это та проблема, которая не решается деньгами.
К примеру, купим мы кластер на 4196 поваров.
Будет ли сборочница работать в 16 раз быстрее? Нет,
будет тормозить как и раньше. Разве что в новом железе
удельная производительность на одно ядро должна быть на 10-15% больше,
следовательно, наш парнишка официант может бегать на 10-15%
быстрее. А может и нет, в процессе выпуска репозитория I/O играет роль
большую, чем CPU.

-- 

I V

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Igor Vlasenko]

On Sun, Aug 30, 2020 at 02:03:00AM +0300, Igor Vlasenko wrote:
> А наша сборочница меня просто раздражает своей медлительностью.
> При чем это та проблема, которая не решается деньгами.

s/деньгами/железом/.

-- 

I V

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Dmitry V. Levin]

On Sun, Aug 30, 2020 at 02:03:00AM +0300, Igor Vlasenko wrote:
> Мухи и котлеты: Основная ошибка дизайна сборочницы.
> ___________________________________________________
> 
> Тема улучшения сборочницы почему-то пугает народ.

С чего это вы взяли?


-- 
ldv

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Igor Vlasenko]

On Sun, Aug 30, 2020 at 02:24:02AM +0300, Dmitry V. Levin wrote:
> On Sun, Aug 30, 2020 at 02:03:00AM +0300, Igor Vlasenko wrote:
> > Мухи и котлеты: Основная ошибка дизайна сборочницы.
> > ___________________________________________________
> > 
> > Тема улучшения сборочницы почему-то пугает народ.
> 
> С чего это вы взяли?

Возможно, пугает - неправильное слово.
Воспринимается с опаской, неодобрением, настороженностью,
недоверием? Ассоциируется со скайнетом, терминатором и нашествием
в Сизиф роботов?
Вызывает надежду, что только специально заторможенная сборочница
сможет сдержать скрипты, готовящие обновления пакетов?

ср. в ходе обсуждения сборочницы:
ldv> Миша, записываю тебя в сторонники превращения Сизифа в autoimports.

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

-- 

I V

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Igor Vlasenko]

On Sun, Aug 30, 2020 at 02:03:00AM +0300, Igor Vlasenko wrote:
> При чем это та проблема, которая не решается железом.

При этом параллельная сборчница, в отличие от нашей,
практически линейно масштабируется на имеющееся железо.

-- 

I V

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Anton Farygin]

On 30.08.2020 02:39, Igor Vlasenko wrote:
> On Sun, Aug 30, 2020 at 02:24:02AM +0300, Dmitry V. Levin wrote:
>> On Sun, Aug 30, 2020 at 02:03:00AM +0300, Igor Vlasenko wrote:
>>> Мухи и котлеты: Основная ошибка дизайна сборочницы.
>>> ___________________________________________________
>>>
>>> Тема улучшения сборочницы почему-то пугает народ.
>> С чего это вы взяли?
> Возможно, пугает - неправильное слово.
> Воспринимается с опаской, неодобрением, настороженностью,
> недоверием? Ассоциируется со скайнетом, терминатором и нашествием
> в Сизиф роботов?
> Вызывает надежду, что только специально заторможенная сборочница
> сможет сдержать скрипты, готовящие обновления пакетов?

ускорение сборочницы никого не пугает, а вот автоматическая сборка 
пакетов из федоры - да, пугает.

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

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Igor Vlasenko]

On Sun, Aug 30, 2020 at 11:49:20AM +0300, Anton Farygin wrote:
> ускорение сборочницы никого не пугает, а вот автоматическая сборка пакетов
> из федоры - да, пугает.
> Т.е. - если целью ускорения сборочницы является увеличение маштабов
> автоимпорта из других дистрибутивов, то мне кажется эта цель порочна.

У меня автоимпорт происходит в autoimports.
И там отдельная сборочница. Но на отдельной кодовой базе, что
плохо размножением велосипедов.
У меня наработан опыт проектирования и использования
параллельной сборочницы для autoimports, и появилось
желание разделить свои наработки по сборочнице с team.

План -
1) провести рефакторинг нашей сборочницы,
выделив локальную сборочницу для пользователей.

2) смержить свои наработки в локальную сборочницу,

3) помочь советом с правильными алгоритмами
для серверной части.


-- 

I V

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Anton Farygin]

On 30.08.2020 11:56, Igor Vlasenko wrote:
> On Sun, Aug 30, 2020 at 11:49:20AM +0300, Anton Farygin wrote:
>> ускорение сборочницы никого не пугает, а вот автоматическая сборка пакетов
>> из федоры - да, пугает.
>> Т.е. - если целью ускорения сборочницы является увеличение маштабов
>> автоимпорта из других дистрибутивов, то мне кажется эта цель порочна.
> У меня автоимпорт происходит в autoimports.
> И там отдельная сборочница. Но на отдельной кодовой базе, что
> плохо размножением велосипедов.
> У меня наработан опыт проектирования и использования
> параллельной сборочницы для autoimports, и появилось
> желание разделить свои наработки по сборочнице с team.
> ра
> План -
> 1) провести рефакторинг нашей сборочницы,
> выделив локальную сборочницу для пользователей.
>
> 2) смержить свои наработки в локальную сборочницу,
>
> 3) помочь советом с правильными алгоритмами
> для серверной части.
>
>
А вот эта цель по мне очень правильная. Просто ещё один взгляд на 
сборочницу точно будет не лишним.

Но её занимается @ldv и решать, принимать Вашу помощь или нет - его стезя.

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Igor Vlasenko]

On Sun, Aug 30, 2020 at 12:18:10PM +0300, Anton Farygin wrote:
> А вот эта цель по мне очень правильная. Просто ещё один взгляд на сборочницу
> точно будет не лишним.
> 
> Но её занимается @ldv и решать, принимать Вашу помощь или нет - его стезя.

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

Поверьте. Распробовав быструю сборочницу, и вы, и Дмитрий
ни за что не захотите возвращаться к нынешней реализации.

-- 

I V

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Igor Vlasenko]

On Sun, Aug 30, 2020 at 12:21:45PM +0300, Aleksey Novodvorsky wrote:
> Вы имеете в виду разработать   дистрибутивную сборочницу?
> Это хорошо. Мы даже обсуждали "в кулуарах" такой продукт и планировали на
> будущий год.

Меня не было, поэтому я не в курсе точного определения 
слов "дистрибутивная сборочница" :(

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

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

Для этого нужно выделить из girar в виде утилит пользователя
компоненты, которые имеет смысл запускать локально:

1) создавать каталог c task и манипулировать task-ом (g-task-new, g-task-add
srpm/git/rebuild/del <arg>, g-task-delsub, g-task-show, ...)

2) Сборка и тестирование task-а (g-build /path/to/taskdir)

3) мерж репозитория и заданного набора тасков.
g-merge /path/to/repo /path/to/task1 ..  /path/to/taskN

4) библиотечка, которая инкапсулирует стркутуру task-каталога,
чтобы в 1)-3)  в код не были жестко вбиты конкретные пути task-каталога

Совокупность этих утилит я и называю локальной сборочницей.
Локальная сборочница даст майнтайнерам полноценную функциональность
текущего girar и при этом позволит разрабатывать и отлаживать
локальную сборочницу, которая содержит большую часть кода текущего
girar, локально, не трогая Дмитрия и сервер.

-- 

I V

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Igor Vlasenko]

On Sun, Aug 30, 2020 at 12:47:20PM +0300, Aleksey Novodvorsky wrote:
> Дистрибутивная -- самостоятельно разворачиваемая из комплекта пакетов.

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

Да, один из вариантов использования.

Для использования дистрибутивной/локальной сборочницы
я вижу 4 основных сценария:

1) оффлайн работа.
Пропал интернет, но мы подготовили пакет, и хотим узнать, 
пройдет ли он тесты. В этом случае новый репозиторий не создается.

2) Сборка пакетов в отдельный репозиторий-оверлей
наподобие autoimports (non-free, media, vasya_pupkin_packages)
В этом случае новый репозиторий создается и публикуется как оверлей к сизифу.

3) Форк сизифа для каких-то целей, к примеру, исследовательских.
К примеру, создаем таск, удаляющий ffmpeg и добавляющий libav
(или другое спорное обновление). Смержив его локально с Сизифом,
получим локально форк Сизифа с libav вместо ffmpeg. 
Далее исследуем локально, что же при этом сломалось сломалось.
В этом случае новый репозиторий создается локально, но не публикуется.

4) Портирование Сизифа на новую архитектуру.
В этом случае новый репозиторий создается и публикуется.


-- 

I V

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Alexey Gladkov]

On Sun, Aug 30, 2020 at 11:49:20AM +0300, Anton Farygin wrote:
> > Возможно, пугает - неправильное слово.
> > Воспринимается с опаской, неодобрением, настороженностью,
> > недоверием? Ассоциируется со скайнетом, терминатором и нашествием
> > в Сизиф роботов?
> > Вызывает надежду, что только специально заторможенная сборочница
> > сможет сдержать скрипты, готовящие обновления пакетов?
> 
> ускорение сборочницы никого не пугает, а вот автоматическая сборка пакетов
> из федоры - да, пугает.
> 
> Т.е. - если целью ускорения сборочницы является увеличение маштабов
> автоимпорта из других дистрибутивов, то мне кажется эта цель порочна.

+100500

Антон, ты офигеннно точно сформулировал.

-- 
Rgrds, legion

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Alexey V. Vissarionov]

On 2020-08-30 12:47:20 +0300, Aleksey Novodvorsky wrote:

 >> Под локальной сборочницей имею в виду тот факт, что в
 >> текущем girar есть много кода, который никаким боком к
 >> серверу не относится и его можно (после рефакторинга)
 >> выделить в отдельный пакет, который можно ставить на
 >> машине пользователя. С его помощью можно будет локально
 >> на стороне пользователя собирать пакеты с проверкой
 >> точно так же, как это делает сборочница сейчас у себя.

Это как минимум сильно разгрузит основную сборочную ферму -
зачастую приходится прогонять несколько итераций только из-за
какой-нибудь ээээ... как бы это назвать без пары мегабайтов
мата... нетривиальной проверки.

 > Но при этом у локальной сборочницу будет свой локальный
 > репозиторий, синхронизируемый с глобальным, так?

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

Например, у меня синхронизация происходит в 8:00 MSK: в это
время коллеги в абсолютном своем большинстве либо уже спят,
либо еще спят, за счет чего процесс получения консистентной
копии заметно ускоряется.

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


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Pavel Nakonechnyi]

вс, 30 авг. 2020 г. в 12:27, Aleksey Novodvorsky <aen@basealt.ru>:
>
> вс, 30 авг. 2020 г., 13:04 Igor Vlasenko <vlasenko@imath.kiev.ua>:
>>
>> On Sun, Aug 30, 2020 at 12:47:20PM +0300, Aleksey Novodvorsky wrote:
>> > Дистрибутивная -- самостоятельно разворачиваемая из комплекта пакетов.
>>
>> да, тогда это то же самое, что я называл локальной сборочницей.
>>
>> > Но при этом у локальной сборочницу будет свой локальный репозиторий,
>> > синхронизируемый с глобальным, так?
>>
>> Да, один из вариантов использования.
>>
>> Для использования дистрибутивной/локальной сборочницы
>> я вижу 4 основных сценария:
>>
>> 1) оффлайн работа.
>> Пропал интернет, но мы подготовили пакет, и хотим узнать,
>> пройдет ли он тесты. В этом случае новый репозиторий не создается.
>>
>> 2) Сборка пакетов в отдельный репозиторий-оверлей
>> наподобие autoimports (non-free, media, vasya_pupkin_packages)
>> В этом случае новый репозиторий создается и публикуется как оверлей к сизифу.
>>
>> 3) Форк сизифа для каких-то целей, к примеру, исследовательских.
>> К примеру, создаем таск, удаляющий ffmpeg и добавляющий libav
>> (или другое спорное обновление). Смержив его локально с Сизифом,
>> получим локально форк Сизифа с libav вместо ffmpeg.
>> Далее исследуем локально, что же при этом сломалось сломалось.
>> В этом случае новый репозиторий создается локально, но не публикуется.
>>
>> 4) Портирование Сизифа на новую архитектуру.
>> В этом случае новый репозиторий создается и публикуется.
>
> Вообще говоря это такой привычный для эмбедщиков продукт, они его называют SDK. С ростом рынка IoT и другой эмбедщины он будет востребован. А интеграция с глобальным репозиторием  позволит  подойти к решению проблемы жизненного цикла софта для подобных изделий, которая актуальна.
>

Ворвусь со скромным комментарием в дискуссию как раз по этому поводу.
Еще порядка девяти лет назад или больше, когда работал над выпуском
embedded устройств в довольно приличных масштабах, вопрос сборки
прошивок стоял ребром. Имеющиеся тогда и сейчас технологии
автоматизации этого процесса просто ужасны, если вы хотите получить
продукт с известным поведением. То есть когда у вас прошивка состоит
из множества пакетов и вам нужно понять из-за какого пакета (какого
его исходника) проблемы на объекте, вам нужна обратная трассировка по
версии прошивки. Это получилось организовать используя `gear/hasher`
локально, с локальным репозиторием и тупой сборочницей на кривом
скрипте. Если бы такая локальная сборочница была тогда.. масса
человеко-часов и боли было бы сэкономлено.


--
WBR, Pavel

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Alexey V. Vissarionov]

On 2020-08-30 11:24:29 +0300, Igor Vlasenko wrote:

 >> При чем это та проблема, которая не решается железом.
 > При этом параллельная сборчница, в отличие от нашей,
 > практически линейно масштабируется на имеющееся железо.

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


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Igor Vlasenko]

On Sun, Aug 30, 2020 at 12:17:15PM +0200, Alexey Gladkov wrote:
> > Т.е. - если целью ускорения сборочницы является увеличение маштабов
> > автоимпорта из других дистрибутивов, то мне кажется эта цель порочна.
> +100500
> Антон, ты офигеннно точно сформулировал.

Еще раз признаюсь, в мои текущие коварные планы
не входит захват Сизифа роботами, а только
улучшение дизайна и ускорение работы нашей сборочницы.

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

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

Хочу привести исторический пример Китая,
который считал себя Поднебесной и плевался
на варваров с их порочными технологиями.
И доплевался до такого дна, что потом 
больше 100 кровавых лет восстанавливал себе
статус великой державы.



-- 

I V

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Alexey V. Vissarionov]

On 2020-08-30 17:16:52 +0300, Alexey Shabalin wrote:


 > Локальная сборочница, как отдельный продукт - это хорошо.
 > Но я не понял как она влияет на ускорение централизованной
 > сборочницы для сизифа и p8,p9,... Как можно доверять результатам
 > какой-то локальной сборочницы безоговорочно? А если вы у себя
 > локально отключили кучу проверок? Вобщем я так и не понял как
 > ускоряет локальная сборочница процесс.

Я в соседнем треде уже объяснил: "зачастую приходится прогонять
несколько итераций только из-за какой-нибудь [...] нетривиальной
проверки".

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


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2809 bytes --]

On Sun, 30 Aug 2020 12:21:45 +0300 Aleksey Novodvorsky wrote:
> вс, 30 авг. 2020 г., 11:56 Igor Vlasenko <vlasenko@imath.kiev.ua>:
> 
> > On Sun, Aug 30, 2020 at 11:49:20AM +0300, Anton Farygin wrote:
> > > ускорение сборочницы никого не пугает, а вот автоматическая сборка
> > пакетов
> > > из федоры - да, пугает.
> > > Т.е. - если целью ускорения сборочницы является увеличение маштабов
> > > автоимпорта из других дистрибутивов, то мне кажется эта цель порочна.
> >
> > У меня автоимпорт происходит в autoimports.
> > И там отдельная сборочница. Но на отдельной кодовой базе, что
> > плохо размножением велосипедов.
> > У меня наработан опыт проектирования и использования
> > параллельной сборочницы для autoimports, и появилось
> > желание разделить свои наработки по сборочнице с team.
> >
> > План -
> > 1) провести рефакторинг нашей сборочницы,
> > выделив локальную сборочницу для пользователей.
> >
> 
> 
> Вы имеете в виду разработать   дистрибутивную сборочницу?
> Это хорошо. Мы даже обсуждали "в кулуарах" такой продукт и планировали на
> будущий год.

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

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

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Alexey Gladkov]

On Sun, Aug 30, 2020 at 03:59:47PM +0300, Igor Vlasenko wrote:
> On Sun, Aug 30, 2020 at 12:17:15PM +0200, Alexey Gladkov wrote:
> > > Т.е. - если целью ускорения сборочницы является увеличение маштабов
> > > автоимпорта из других дистрибутивов, то мне кажется эта цель порочна.
> > +100500
> > Антон, ты офигеннно точно сформулировал.
> 
> Еще раз признаюсь, в мои текущие коварные планы
> не входит захват Сизифа роботами, а только
> улучшение дизайна и ускорение работы нашей сборочницы.

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

Если хочется каждую минуту через сборочницу пропихивать слона из 1000
пакетов, то вы явно делаете что-то не то.

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

> Что же касается в целом перспектив автоматизации/роботизации,
> то воевать с ней мне кажется так же бессмысленным,
> как воевать 100 лет назад за права извозчиков
> против захвата улиц автомобилистами или сейчас
> устраивать забастовки таксистов против испытаний
> беспилотных автомобилей в яндексе.
> 
> Другое дело, что локально эта война может
> увенчаться успехом, с плачевными последствиями
> для нашего дистрибутива.
> 
> Хочу привести исторический пример Китая,
> который считал себя Поднебесной и плевался
> на варваров с их порочными технологиями.
> И доплевался до такого дна, что потом 
> больше 100 кровавых лет восстанавливал себе
> статус великой державы.

Вы в свои письма вставляете очень длинные лирические не технические
отступления из-за чего их очень сложно читать и комментировать.

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

-- 
Rgrds, legion

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2664 bytes --]

On Sun, 30 Aug 2020 17:38:53 +0200 Alexey Gladkov wrote:
> On Sun, Aug 30, 2020 at 03:59:47PM +0300, Igor Vlasenko wrote:
> > On Sun, Aug 30, 2020 at 12:17:15PM +0200, Alexey Gladkov wrote:
> > > > Т.е. - если целью ускорения сборочницы является увеличение маштабов
> > > > автоимпорта из других дистрибутивов, то мне кажется эта цель порочна.
> > > +100500
> > > Антон, ты офигеннно точно сформулировал.
> > 
> > Еще раз признаюсь, в мои текущие коварные планы
> > не входит захват Сизифа роботами, а только
> > улучшение дизайна и ускорение работы нашей сборочницы.
> 
> Лично я не вижу проблем с текущей производительностью сборочницы. Я не
> увидел конкретных примеров юскейсов, где это было действительно нужно.

На догоняющих архитектурах приходится отключать install check,
потому что нереалистично его выполнять.

> Пока же все разговоры про переделку сборочницы идут ради самой переделки.

Вы явно не висели в очереди, пока сутки-двое qt/kde или ещё что
тяжёлое пересобирается, или пока сборочница заблокирована ради
обновления python/perl/т.п..

> Если хочется каждую минуту через сборочницу пропихивать слона из 1000
> пакетов, то вы явно делаете что-то не то.
> 
> Да, бывают редкие большие задачи с большим количеством пакетов внутри,
> которые долго выполняются, но такие задачи появляются не часто. Да и не
> всегда есть необходимость всё пихать в одну таску и можно воспользоваться
> зависимостями между тасками.

А бывают задачи, которые сборчница вообще прожевать не способна,
например, нормально разбитый на подпакеты TeXlive, а не как сейчас.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Alexey Gladkov]

On Sun, Aug 30, 2020 at 06:46:32PM +0300, Andrey Savchenko wrote:
> > Лично я не вижу проблем с текущей производительностью сборочницы. Я не
> > увидел конкретных примеров юскейсов, где это было действительно нужно.
> 
> На догоняющих архитектурах приходится отключать install check,
> потому что нереалистично его выполнять.

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

> > Пока же все разговоры про переделку сборочницы идут ради самой переделки.
> 
> Вы явно не висели в очереди, пока сутки-двое qt/kde или ещё что
> тяжёлое пересобирается, или пока сборочница заблокирована ради
> обновления python/perl/т.п..

Вы смеётесь ?! Мои пакеты как раз в первую очередь "страдают" от таких
обновлений т.к. собираются часы и с большой вероятностью их затрагивают
perl/python и хрен знает ещё что. Из-за этого мои задания пересобираются
по нескольку раз.

Я не вижу в этом проблемы. Если произошло наложение жирных заданий, то
пакет может подождать. Если у вас в пакете супер важный фикс супер
страшного CVE, то нет проблем написать про это и ваше задание пропустят.

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

> > Если хочется каждую минуту через сборочницу пропихивать слона из 1000
> > пакетов, то вы явно делаете что-то не то.
> > 
> > Да, бывают редкие большие задачи с большим количеством пакетов внутри,
> > которые долго выполняются, но такие задачи появляются не часто. Да и не
> > всегда есть необходимость всё пихать в одну таску и можно воспользоваться
> > зависимостями между тасками.
> 
> А бывают задачи, которые сборчница вообще прожевать не способна,
> например, нормально разбитый на подпакеты TeXlive, а не как сейчас.

Что вы имеете в виду под "прожевать не способна" ?

-- 
Rgrds, legion

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Michael Shigorin]

On Sun, Aug 30, 2020 at 06:09:06PM +0200, Alexey Gladkov wrote:
> > > Лично я не вижу проблем с текущей производительностью сборочницы. Я не
> > > увидел конкретных примеров юскейсов, где это было действительно нужно.
> > На догоняющих архитектурах приходится отключать install check,
> > потому что нереалистично его выполнять.
> На мой взгляд это проблема производительности этих догоняющих архитектур.

Лёш, последние лет пятнадцать однопоточный дизайн в принципе
распараллеливаемых вещей -- это проблема именно дизайна.

> > А бывают задачи, которые сборчница вообще прожевать не способна,
> > например, нормально разбитый на подпакеты TeXlive, а не как сейчас.
> Что вы имеете в виду под "прожевать не способна" ?

---
> Но это вынужденная ситуация. Я готовил как раз очень тщательно
> порезанную сборку texlive, гле все отдельные проекты упакованы
> в 2-3 отдельных пакета {,-bin,-doc}. Получилось более 6000 пакетов,
> и, к сожалению, в итоге подвела сборочница. Она оказалась не
> рассчитана на такую нагрузку. Оптимизированная сборка прошла за
> час, но потом тестирование транзакции инсталляцией заняло 10+ суток.
--- http://lists.altlinux.org/pipermail/sisyphus/2018-March/366548.html

(опять выручил recoll, а вот гугль на search.altlinux.org
уже несколько лет как не находит заведомо существующие
в архиве письма -- похоже, придётся напрячься и сделать
снова свой поиск, только теперь не на mnogosearch)

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 4531 bytes --]

On Sun, 30 Aug 2020 18:09:06 +0200 Alexey Gladkov wrote:
> On Sun, Aug 30, 2020 at 06:46:32PM +0300, Andrey Savchenko wrote:
> > > Лично я не вижу проблем с текущей производительностью сборочницы. Я не
> > > увидел конкретных примеров юскейсов, где это было действительно нужно.
> > 
> > На догоняющих архитектурах приходится отключать install check,
> > потому что нереалистично его выполнять.
> 
> На мой взгляд это проблема производительности этих догоняющих архитектур.

Это индикатор того, что текущая сборочница близка к пределу
оборудования и у неё нет запаса роста с ростом сложности задач:
а они растут, потому что софта становится больше, он становится
тяжелее, компиляторы и прочие ресурсы сборки становятся всё более
ресурсоёмкими.

И поскольку Альт ориентируется на большое количество платформа,
производительность неинтеловых архитектур следует учитывать в
архитектуре нашей сборочнице.

> > > Пока же все разговоры про переделку сборочницы идут ради самой переделки.
> > 
> > Вы явно не висели в очереди, пока сутки-двое qt/kde или ещё что
> > тяжёлое пересобирается, или пока сборочница заблокирована ради
> > обновления python/perl/т.п..
> 
> Вы смеётесь ?! Мои пакеты как раз в первую очередь "страдают" от таких
> обновлений т.к. собираются часы и с большой вероятностью их затрагивают
> perl/python и хрен знает ещё что. Из-за этого мои задания пересобираются
> по нескольку раз.
> 
> Я не вижу в этом проблемы. Если произошло наложение жирных заданий, то
> пакет может подождать. Если у вас в пакете супер важный фикс супер
> страшного CVE, то нет проблем написать про это и ваше задание пропустят.
> 
> Ещё раз. Я не видел юскейсов, когда текущая производительность сборочницы
> мешала бы в моей работе. Это не значит, что их нет. Если вы знаете такие,
> то перечислите их без странных аллегорий про дороги, китай и т.д.

Я не могу перечислить что мешает *Вашей* работе. Судя по Вашему
комментарию, Вас вполне устраивает несколько суток ожидания
выполнения задания.

Я могу сказать, что в моей работе, как минимум, текущая реализация
install check мешает.

> > > которые долго выполняются, но такие задачи появляются не часто. Да и не
> > > всегда есть необходимость всё пихать в одну таску и можно воспользоваться
> > > зависимостями между тасками.
> > 
> > А бывают задачи, которые сборчница вообще прожевать не способна,
> > например, нормально разбитый на подпакеты TeXlive, а не как сейчас.
> 
> Что вы имеете в виду под "прожевать не способна" ?

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

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Alexey Gladkov]

On Sun, Aug 30, 2020 at 07:25:32PM +0300, Michael Shigorin wrote:
> On Sun, Aug 30, 2020 at 06:09:06PM +0200, Alexey Gladkov wrote:
> > > > Лично я не вижу проблем с текущей производительностью сборочницы. Я не
> > > > увидел конкретных примеров юскейсов, где это было действительно нужно.
> > > На догоняющих архитектурах приходится отключать install check,
> > > потому что нереалистично его выполнять.
> > На мой взгляд это проблема производительности этих догоняющих архитектур.
> 
> Лёш, последние лет пятнадцать однопоточный дизайн в принципе
> распараллеливаемых вещей -- это проблема именно дизайна.

Это очень упрощённая точка зрения.

> > > А бывают задачи, которые сборчница вообще прожевать не способна,
> > > например, нормально разбитый на подпакеты TeXlive, а не как сейчас.
> > Что вы имеете в виду под "прожевать не способна" ?
> 
> ---
> > Но это вынужденная ситуация. Я готовил как раз очень тщательно
> > порезанную сборку texlive, гле все отдельные проекты упакованы
> > в 2-3 отдельных пакета {,-bin,-doc}. Получилось более 6000 пакетов,
> > и, к сожалению, в итоге подвела сборочница. Она оказалась не
> > рассчитана на такую нагрузку. Оптимизированная сборка прошла за
> > час, но потом тестирование транзакции инсталляцией заняло 10+ суток.
> --- http://lists.altlinux.org/pipermail/sisyphus/2018-March/366548.html

Я не видел как сделаны пакеты поэтому могу только гадать. Но при размере
задания в 6000 пакетов я не уверен, что тут что-нибудь сможет помочь.
Также долгое время обработки это не "вообще прожевать не способна".

Ок, юскейс: задание с 6000 пакетов долго тестируется. Хотя, для меня
звучит забавно.

Какие ещё ?

> (опять выручил recoll, а вот гугль на search.altlinux.org
> уже несколько лет как не находит заведомо существующие
> в архиве письма -- похоже, придётся напрячься и сделать
> снова свой поиск, только теперь не на mnogosearch)

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

-- 
Rgrds, legion

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Alexey Gladkov]

On Sun, Aug 30, 2020 at 07:27:00PM +0300, Andrey Savchenko wrote:
> > > На догоняющих архитектурах приходится отключать install check,
> > > потому что нереалистично его выполнять.
> > 
> > На мой взгляд это проблема производительности этих догоняющих архитектур.
> 
> Это индикатор того, что текущая сборочница близка к пределу
> оборудования и у неё нет запаса роста с ростом сложности задач:
> а они растут, потому что софта становится больше, он становится
> тяжелее, компиляторы и прочие ресурсы сборки становятся всё более
> ресурсоёмкими.
> 
> И поскольку Альт ориентируется на большое количество платформа,
> производительность неинтеловых архитектур следует учитывать в
> архитектуре нашей сборочнице.

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

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

> > > > Пока же все разговоры про переделку сборочницы идут ради самой переделки.
> > > 
> > > Вы явно не висели в очереди, пока сутки-двое qt/kde или ещё что
> > > тяжёлое пересобирается, или пока сборочница заблокирована ради
> > > обновления python/perl/т.п..
> > 
> > Вы смеётесь ?! Мои пакеты как раз в первую очередь "страдают" от таких
> > обновлений т.к. собираются часы и с большой вероятностью их затрагивают
> > perl/python и хрен знает ещё что. Из-за этого мои задания пересобираются
> > по нескольку раз.
> > 
> > Я не вижу в этом проблемы. Если произошло наложение жирных заданий, то
> > пакет может подождать. Если у вас в пакете супер важный фикс супер
> > страшного CVE, то нет проблем написать про это и ваше задание пропустят.
> > 
> > Ещё раз. Я не видел юскейсов, когда текущая производительность сборочницы
> > мешала бы в моей работе. Это не значит, что их нет. Если вы знаете такие,
> > то перечислите их без странных аллегорий про дороги, китай и т.д.
> 
> Я не могу перечислить что мешает *Вашей* работе. Судя по Вашему
> комментарию, Вас вполне устраивает несколько суток ожидания
> выполнения задания.

Да. Вы меня правильно поняли.

> Я могу сказать, что в моей работе, как минимум, текущая реализация
> install check мешает.
> 
> > > > которые долго выполняются, но такие задачи появляются не часто. Да и не
> > > > всегда есть необходимость всё пихать в одну таску и можно воспользоваться
> > > > зависимостями между тасками.
> > > 
> > > А бывают задачи, которые сборчница вообще прожевать не способна,
> > > например, нормально разбитый на подпакеты TeXlive, а не как сейчас.
> > 
> > Что вы имеете в виду под "прожевать не способна" ?
> 
> Не смогла за разумное время обработать задание, которое в итоге
> было прервано администатором сборочницы.

Ок. В соседнем письме я писал, что занёс юскейс с заданием с 6000 пакетов.

-- 
Rgrds, legion

[devel] параллельный install check (was: Мухи и котлеты: основная ошибка дизайна сборочницы)

[Michael Shigorin]

On Sun, Aug 30, 2020 at 07:06:24PM +0200, Alexey Gladkov wrote:
> > > > > Лично я не вижу проблем с текущей производительностью сборочницы. Я не
> > > > > увидел конкретных примеров юскейсов, где это было действительно нужно.
> > > > На догоняющих архитектурах приходится отключать install check,
> > > > потому что нереалистично его выполнять.
> > > На мой взгляд это проблема производительности этих догоняющих архитектур.
> > Лёш, последние лет пятнадцать однопоточный дизайн в принципе
> > распараллеливаемых вещей -- это проблема именно дизайна.
> Это очень упрощённая точка зрения.

Можно усложнить, но в физическом мире эта точка зрения
обусловлена резким снижением скорости роста производительности
одного процессорного ядра (интел пытался жульничать, что лишь
вылилось в череду фундаментальных изъянов, многие из которых
характерны именно для его варианта x86).

> > > > А бывают задачи, которые сборчница вообще прожевать не способна,
> > > > например, нормально разбитый на подпакеты TeXlive, а не как сейчас.
> > > Что вы имеете в виду под "прожевать не способна" ?
> > ---
> > > Но это вынужденная ситуация. Я готовил как раз очень тщательно
> > > порезанную сборку texlive, гле все отдельные проекты упакованы
> > > в 2-3 отдельных пакета {,-bin,-doc}. Получилось более 6000 пакетов,
> > > и, к сожалению, в итоге подвела сборочница. Она оказалась не
> > > рассчитана на такую нагрузку. Оптимизированная сборка прошла за
> > > час, но потом тестирование транзакции инсталляцией заняло 10+ суток.
> > --- http://lists.altlinux.org/pipermail/sisyphus/2018-March/366548.html
> Я не видел как сделаны пакеты поэтому могу только гадать. Но при размере
> задания в 6000 пакетов я не уверен, что тут что-нибудь сможет помочь.
> Также долгое время обработки это не "вообще прожевать не способна".
> Ок, юскейс: задание с 6000 пакетов долго тестируется. Хотя, для меня
> звучит забавно.

Это примерно 1/8 от текущих бинарных пакетов в sisyphus/x86_64,
если что.  Просто именно в рамках _одного_ сборочного задания
это оказывается фатально.

> > (опять выручил recoll, а вот гугль на search.altlinux.org
> > уже несколько лет как не находит заведомо существующие
> > в архиве письма -- похоже, придётся напрячься и сделать
> > снова свой поиск, только теперь не на mnogosearch)
> Некоторое время назад я нескольким коллегам предлагал поднять
> lore для альтовых рассылок, но у меня не получилось
> заинтересовать.

Ммм... насколько понимаю, он всё-таки под патчи заточен,
хотя поиск тоже есть и работает.  Давай об этом отдельно
пошушукаемся и поставим в копию jenya@.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Igor Vlasenko]

On Sun, Aug 30, 2020 at 05:16:52PM +0300, Alexey Shabalin wrote:
> Локальная сборочница, как отдельный продукт - это хорошо.
> Но я не понял как она влияет на ускорение централизованной сборочницы для
> сизифа и p8,p9,...

Действительно, в зачинателе темы, письме # Мухи и котлеты: ...
https://lists.altlinux.org/pipermail/devel/2020-August/211678.html
я писал о боттлнеке в алгоритме на серверной стороне
(пример с поварами и официантками).

Тему ускорения работы именно локальной сборочницы я упомянул
в письме # incoming/girar: проблема производительности.
https://lists.altlinux.org/pipermail/devel/2020-August/211601.html
но подробно не развивал.

У меня есть несколько нароботок на эту тему.
Одна из них связана с изменениями в hasher
для повторного использования hasher's 
initroot-only workdir, при условии, если сборка
происходит относительно неизменного репозитория
(скажем, дневное зеркало Сизифа).

Вторая описана на
https://www.altlinux.org/Girar/Parallel#VII._Алгоритмы_ускорения_сборки_Больших_Транзакций.

Есть и еще наметки, но без локальной сборочницы
как их пробовать и тестировать?

> Как можно доверять результатам какой-то локальной сборочницы безоговорочно?

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

Установить страндартный пакет локальной сборочницы, 
сформировать тестовый таск, запустить на сборку, 
провести бенчмарки времени, CPU, IO.

Посмотреть патчи кандидата на улучшение сборки.
Самому убедиться, не сжульничал ли, не отключил
ли проверки. Самому собрать и установить его
код, самому получить бенчмарки нового кода
и самому убедиться, есть ли в итоге ускорение
сборочницы.

-- 

I V

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Anton Farygin]

On 30.08.2020 17:16, Alexey Shabalin wrote:
> Как можно доверять результатам какой-то локальной сборочницы 
> безоговорочно? А если вы у себя локально отключили кучу проверок?

Более того - мы точно знаем, что локально сборочницу не повторить, т.к. 
её работа сильно зависит от версии и настроек ядра сборочной ноды.

И, с некоторой долей вероятности, от поколения и производителя процессора.

Re: [devel] install check refactoring

[Anton Farygin]

On 30.08.2020 18:38, Alexey Gladkov wrote:
> On Sun, Aug 30, 2020 at 03:59:47PM +0300, Igor Vlasenko wrote:
>> On Sun, Aug 30, 2020 at 12:17:15PM +0200, Alexey Gladkov wrote:
>>>> Т.е. - если целью ускорения сборочницы является увеличение маштабов
>>>> автоимпорта из других дистрибутивов, то мне кажется эта цель порочна.
>>> +100500
>>> Антон, ты офигеннно точно сформулировал.
>> Еще раз признаюсь, в мои текущие коварные планы
>> не входит захват Сизифа роботами, а только
>> улучшение дизайна и ускорение работы нашей сборочницы.
> Лично я не вижу проблем с текущей производительностью сборочницы. Я не
> увидел конкретных примеров юскейсов, где это было действительно нужно.
> Пока же все разговоры про переделку сборочницы идут ради самой переделки.

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

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

И этого слона точно удобнее было бы есть по чуть чуть.

Re: [devel] install check refactoring

[Igor Vlasenko]

On Sun, Aug 30, 2020 at 08:48:46PM +0300, Anton Farygin wrote:
> На мой взгляд, решение нескольких очевидных задач по оптимизации, одна и
> самая явная из которых - параллельный install check, закрыла бы вопрос
> ускорения сборочницы на ближайшую перспективу.

Это, кстати, еще один пример задачи на оптимизацию работы,
которую можно целиком решить и протестировать в рамках
дистрибутивной/локальной сборочницы, не трогая сервер.
Конечно, после того, как в рамках рефакторинга
локальная сборочница будет из girar выпилена в отдельный пакет.

В качестве иллюстрации на вопрос Алексея Шабалина.

-- 

I V

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Igor Vlasenko]

On Sun, Aug 30, 2020 at 08:42:05PM +0300, Anton Farygin wrote:
> Более того - мы точно знаем, что локально сборочницу не повторить, т.к. её
> работа сильно зависит от версии и настроек ядра сборочной ноды.
> 
> И, с некоторой долей вероятности, от поколения и производителя процессора.

Гм. есть понятие алгоритма работы.
Чтобы сказать, что в алгоритме работы нынешней сборчницы
есть затык, не обязательно поднимать ее копию.

-- 

I V

Re: [devel] install check refactoring

[Alexey Gladkov]

On Sun, Aug 30, 2020 at 08:48:46PM +0300, Anton Farygin wrote:
> > > > +100500
> > > > Антон, ты офигеннно точно сформулировал.
> > > Еще раз признаюсь, в мои текущие коварные планы
> > > не входит захват Сизифа роботами, а только
> > > улучшение дизайна и ускорение работы нашей сборочницы.
> > Лично я не вижу проблем с текущей производительностью сборочницы. Я не
> > увидел конкретных примеров юскейсов, где это было действительно нужно.
> > Пока же все разговоры про переделку сборочницы идут ради самой переделки.
> 
> На мой взгляд, решение нескольких очевидных задач по оптимизации, одна и
> самая явная из которых - параллельный install check, закрыла бы вопрос
> ускорения сборочницы на ближайшую перспективу.
> 
> Более того, в параллельной реальности висит таск на решение этой задачи, но
> пока что руки до него не дошли. Вот если бы Игорь смог бы взяться за решение
> ровно этой задачи, согласовав с Димой архитектуру этого изменения, то пользы
> было бы намного больше, чем полная переделка сборочницы с просёлочной дороги
> на сверхскоростную железную дорогу с магнитной подушкой.
> 
> И этого слона точно удобнее было бы есть по чуть чуть.

Я с тобой полностью согласен.

-- 
Rgrds, legion

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Sergey V Turchin]

On Sunday, 30 August 2020 18:38:53 MSK Alexey Gladkov wrote:

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

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

[...]

-- 
Regards, Sergey.

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Sergey V Turchin]

On Sunday, 30 August 2020 18:46:32 MSK Andrey Savchenko wrote:

[...]
> Вы явно не висели в очереди, пока сутки-двое qt/kde или ещё что
> тяжёлое пересобирается
Это я их ещё на части делю.

[...]

-- 
Regards, Sergey.

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Konstantin Lepikhov]

Hi Aleksey!

On 08/30/2020, at 01:26:45 PM you wrote:

<skip>
> Вообще говоря это такой привычный для эмбедщиков продукт, они его называют
> SDK. С ростом рынка IoT и другой эмбедщины он будет востребован. А
> интеграция с глобальным репозиторием  позволит  подойти к решению проблемы
> жизненного цикла софта для подобных изделий, которая актуальна.
> 
> Rgrds, Алексей
Красивые слова, в суровой реальности важна не итеграция с глобальным
репозиторием а срок паразитирования на дистрибутиве-доноре aka
RHEL/Ubuntu, который пока у продуктов ООО стремится к нулю. Под
паразитированием я имею ввиду не дистрибутив а OEM/firmware/NDA
производителей. И в этом случае достаточно ABI совместимости toolchain с
донором (привет, Эльбрус).

Конечно, сейчас в России все окукливается и все импортозамещается но тем не
менее.

-- 
WBR et al.

Re: [devel] Мухи и котлеты: основная ошибка дизайна сборочницы.

[Alexey Tourbin]

On Sun, Aug 30, 2020, 13:04 Igor Vlasenko <vlasenko@imath.kiev.ua> wrote:
> On Sun, Aug 30, 2020 at 12:47:20PM +0300, Aleksey Novodvorsky wrote:
> > Дистрибутивная -- самостоятельно разворачиваемая из комплекта пакетов.
>
> да, тогда это то же самое, что я называл локальной сборочницей.
>
> > Но при этом у локальной сборочницу будет свой локальный репозиторий,
> > синхронизируемый с глобальным, так?
>
> Да, один из вариантов использования.
>
> Для использования дистрибутивной/локальной сборочницы
> я вижу 4 основных сценария:
>
> 1) оффлайн работа.
> Пропал интернет, но мы подготовили пакет, и хотим узнать,
> пройдет ли он тесты. В этом случае новый репозиторий не создается.

Почему-то никто не написал очевидного возражения: существенной чертой
сборочной системы является синхронная сборка для нескольких
архитектур. Поэтому сборочную систему нелегко будет поднять
"локально", нужно будет реплицировать и сборочные узлы для нескольких
архитектур. А это требует отдельного железа, т.к. сборка в qemu идет
слишком медленно. Для более или менее полноценного разворачивания
сборочной системы нужна сетевая сборочная инфраструктура, которая
потребует поддержки. По сравнению с "пропаданием интернета" цена
разворачивание сборочной системы будет не меньше, а больше.

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

> 2) Сборка пакетов в отдельный репозиторий-оверлей
> наподобие autoimports (non-free, media, vasya_pupkin_packages)
> В этом случае новый репозиторий создается и публикуется как оверлей к сизифу.
>
> 3) Форк сизифа для каких-то целей, к примеру, исследовательских.
> К примеру, создаем таск, удаляющий ffmpeg и добавляющий libav
> (или другое спорное обновление). Смержив его локально с Сизифом,
> получим локально форк Сизифа с libav вместо ffmpeg.
> Далее исследуем локально, что же при этом сломалось сломалось.
> В этом случае новый репозиторий создается локально, но не публикуется.
>
> 4) Портирование Сизифа на новую архитектуру.
> В этом случае новый репозиторий создается и публикуется.

Re: [devel] install check refactoring

[Anton Farygin]

On 30.08.2020 20:48, Anton Farygin wrote:
> On 30.08.2020 18:38, Alexey Gladkov wrote:
>> On Sun, Aug 30, 2020 at 03:59:47PM +0300, Igor Vlasenko wrote:
>>> On Sun, Aug 30, 2020 at 12:17:15PM +0200, Alexey Gladkov wrote:
>>>>> Т.е. - если целью ускорения сборочницы является увеличение маштабов
>>>>> автоимпорта из других дистрибутивов, то мне кажется эта цель порочна.
>>>> +100500
>>>> Антон, ты офигеннно точно сформулировал.
>>> Еще раз признаюсь, в мои текущие коварные планы
>>> не входит захват Сизифа роботами, а только
>>> улучшение дизайна и ускорение работы нашей сборочницы.
>> Лично я не вижу проблем с текущей производительностью сборочницы. Я не
>> увидел конкретных примеров юскейсов, где это было действительно нужно.
>> Пока же все разговоры про переделку сборочницы идут ради самой 
>> переделки.
>
> На мой взгляд, решение нескольких очевидных задач по оптимизации, одна 
> и самая явная из которых - параллельный install check, закрыла бы 
> вопрос ускорения сборочницы на ближайшую перспективу.
>
> Более того, в параллельной реальности висит таск на решение этой 
> задачи, но пока что руки до него не дошли. Вот если бы Игорь смог бы 
> взяться за решение ровно этой задачи, согласовав с Димой архитектуру 
> этого изменения, то пользы было бы намного больше, чем полная 
> переделка сборочницы с просёлочной дороги на сверхскоростную железную 
> дорогу с магнитной подушкой.
>
> И этого слона точно удобнее было бы есть по чуть чуть.
Я правильно понимаю, что сегодня сборочная очередь для всех пакетов в 
Sisyphus была заблокирована на 6 часов процессом install check в этом 
задании:

http://git.altlinux.org/tasks/286638/logs/events.2.3.log  ?

Re: [devel] install check refactoring

[Dmitry V. Levin]

On Tue, Oct 12, 2021 at 09:55:28PM +0300, Anton Farygin wrote:
> On 30.08.2020 20:48, Anton Farygin wrote:
> > On 30.08.2020 18:38, Alexey Gladkov wrote:
> >> On Sun, Aug 30, 2020 at 03:59:47PM +0300, Igor Vlasenko wrote:
> >>> On Sun, Aug 30, 2020 at 12:17:15PM +0200, Alexey Gladkov wrote:
> >>>>> Т.е. - если целью ускорения сборочницы является увеличение маштабов
> >>>>> автоимпорта из других дистрибутивов, то мне кажется эта цель порочна.
> >>>> +100500
> >>>> Антон, ты офигеннно точно сформулировал.
> >>> Еще раз признаюсь, в мои текущие коварные планы
> >>> не входит захват Сизифа роботами, а только
> >>> улучшение дизайна и ускорение работы нашей сборочницы.
> >> Лично я не вижу проблем с текущей производительностью сборочницы. Я не
> >> увидел конкретных примеров юскейсов, где это было действительно нужно.
> >> Пока же все разговоры про переделку сборочницы идут ради самой 
> >> переделки.
> >
> > На мой взгляд, решение нескольких очевидных задач по оптимизации, одна 
> > и самая явная из которых - параллельный install check, закрыла бы 
> > вопрос ускорения сборочницы на ближайшую перспективу.
> >
> > Более того, в параллельной реальности висит таск на решение этой 
> > задачи, но пока что руки до него не дошли. Вот если бы Игорь смог бы 
> > взяться за решение ровно этой задачи, согласовав с Димой архитектуру 
> > этого изменения, то пользы было бы намного больше, чем полная 
> > переделка сборочницы с просёлочной дороги на сверхскоростную железную 
> > дорогу с магнитной подушкой.
> >
> > И этого слона точно удобнее было бы есть по чуть чуть.
> Я правильно понимаю, что сегодня сборочная очередь для всех пакетов в 
> Sisyphus была заблокирована на 6 часов процессом install check в этом 
> задании:
> 
> http://git.altlinux.org/tasks/286638/logs/events.2.3.log  ?

С 2021-Oct-12 11:10:52 до 2021-Oct-12 17:15:36 (по самой медленной
архитектуре).  Это было без кеширования результатов тестирования
на предыдущей итерации, поскольку на этой итерации из-за какого-то
изменения сборочной среды все пакеты были собраны заново.

На тему параллелизации install check был заведён FR:
https://bugzilla.altlinux.org/40249


-- 
ldv