devconf.cz Поддержка ядра корпоративного дистрибутива — это не только тяжелая работа, но и противоречивые цели.
В выступлении главного инженера ядра Red Hat Йиржи Бенка на мероприятии DevConf.cz в этом году были рассмотрены некоторые противоречия, присущие поддержанию ядра корпоративного дистрибутива на ногах. Или, по крайней мере, на чьей-то или чьей-то ноге, как намекает ее название: «CentOS Frankenkernel: Append Your Limb».
Он сосредоточился на ядре CentOS Stream, которое со временем станет ядром следующего точечного выпуска RHEL 9 — на момент написания это будет RHEL 9.3, но, как и другие версии RHEL 9, у этого будет ядро 5.14 — выпущено еще 29 августа 2021 года. Как они этого добиваются?
Цели любого обновления ядра просты: стабильность, очевидно. Никаких регрессий, а это также означает отсутствие регрессий производительности. Никаких изменений API и внутреннего ABI: фактически никаких изменений в поведении. Но в то же время клиентам нужны новые функции и поддержка нового оборудования, включая новые драйверы; им нужны обновления, по крайней мере, любые ожидающие обновления безопасности. И все это без нарушения того, что они сейчас используют, потому что именно за это они и платят.
Это большая просьба, и результатом неизбежно должен быть компромисс. Команда старается не допускать функциональных регрессий и ограничивать регрессии производительности важными вещами. Чтобы не вносить обратно несовместимые изменения microAPI и избегать изменений ABI ядра для важных вещей. Проблема в том, что людям нужны новые функции… и новые или обновленные драйверы.
Итак, то, над чем работает команда, — это монстр Франкенштейна, сшитый из разных кодовых баз. Хотя базовое ядро по-прежнему имеет версию 5.14, оно полно бэкпортов из апстрима. Он имеет код файловой системы XFS из ядра 6.0, подсистему USB с драйверами и подсистему BPF из ядра 6.2, беспроводной стек и все драйверы из ядра 6.3, а также многопутевой код TCP/IP из ядра 6.4, который в то время разговор еще даже не был выпущен вверх по течению. (Он был выпущен в минувшие выходные.)
Он работает из-за много тестирования и очень осторожного процесса выпуска. Конечно, его тестирует сам разработчик, но он также проходит тестирование непрерывной интеграции благодаря инструментам проекта CKI, а также тестирование сетевого стека с использованием инструментов LNST. Затем он проходит предварительную проверку, то есть человек — кто-то, кроме автора, — вручную проверяет изменение. Только после этого изменение вливается в дерево ядра CentOS, после чего оно проходит интеграционное тестирование: проверяется на наличие еще 150 или около того незавершенных изменений. Затем, после того, как он прошел все эти испытания, он проходит обычное тестирование QA с остальной частью ОС.
Результаты можно увидеть в Gitlab CentOS Stream — Бенк стремился подчеркнуть, что все это происходит публично, и все это задокументировано. Действительно, любой может открыть запрос на такое изменение, отправив сообщение об ошибке в Bugzilla или открыв задачу JIRA в соответствии с установленным форматом: Продукт… Версия… Компонент… Подкомпонент… Выгода… Тесты. Точно так же существует очень строгий формат для мерж-реквестов (которые являются Gitlab-эквивалентом Github-реквестов на вытягивание) и для сообщений коммитов — и ему нужно точно следовать, потому что сообщения анализируются машинами так же, как и людьми.
Пока формат соблюдается точно, в дело вступает автоматизация. Она добавляет множество меток, проверяет наличие последующих исправлений и исправлений из основной ветки разработки, помечает различных людей, которые должны проверять и проверять изменения, и многое другое. Все обсуждения ведутся в комментариях к самому MR на Gitlab — за исключением зависимостей, таких как драйверы, потому что Gitlab в настоящее время не может с этим справиться.
Если вы внимательно послушаете трансляцию выступления на Youtube, первый вопрос был от отдела Reg FOSS, который спросил, не пересекается ли это с работой над выпусками долгосрочной поддержки от разработчиков основного ядра. Бенк сказал нам, что, по его мнению, уровень тестирования и контроля качества Red Hat превышает уровень вышестоящих LTS-ядер и что они не обеспечивают уровень стабильности, необходимый корпоративному дистрибутиву.
Это было довольно неожиданно для нас, но это, несомненно, впечатляющий объем работы и уровень внимания к деталям. В свете непрекращающегося фурора, последовавшего за отзывом Red Hat исходного кода RHEL из публикации, в докладе подчеркивался огромный объем работы, который требуется для поддержки дистрибутива с одной версией ядра в течение жизненного цикла целое десятилетие. Например, поддержка RHEL 9.10 не планируется до 2032 года.
Это та работа, за которую Red Hat хочет получать деньги, и причина, по которой она все еще пытается найти способы исключить последующие перестройки, как она это делала в течение дюжины лет. ®
