Вот‑вот выйдет Octavia 2026.2 — что в OpenStack приготовили всем

Всем привет! Меня зовут Крайнев Сергей, я работаю старшим бекэнд-разработчиком в Selectel. Поскольку в нашем публичном облаке используются компоненты OpenStack, мы следим за развитием основных веток этих проектов.

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

Свежий функционал

В этом разделе отмечены три изменения:

• ускорение обработки GET‑запросов для балансировщиков с большим числом ресурсов;

• новая конфигурационная опция denylist_vip_networks;

• модификация параметра архитектуры при сборке образа амфоры.

Рассмотрим каждое из них подробнее.

Сборка образа амфоры

При сборке образа амфоры можно указать опцию -a. Она характеризует, какой тип архитектуры будет использован при сборке итогового образа. Возможные значения: amd64, armhf, arm64, aarch64 и ppc64le. 

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

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

Новая функция denylist_vip_networks

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

Такой «черный список» пригодится при наличии общедоступной (разделяемой) сети, которую владельцы облака хотят скрыть при создании балансировщиков.

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

Модификация логики программный оболочку GET‑запросов

На мой взгляд, смена логики обработки запросов — наиболее интересное изменение в релизе. Оно нацелено на улучшение работы с крупными балансировщиками, которые часто создаются с помощью автоматизации Kubernetes и библиотеки gophercloud. Особенность таких балансировщиков заключается в том, что они могут содержать более 200 вложенных ресурсов — в частности, 40 листенеров, в каждом — по одному пулу с 40 серверами.

В оригинальном отчете об ошибке^[1] упоминаются на порядок бо́льшие значения, тем не менее проблема наблюдалась и на приведенном выше примере^[2]. Запросы на получение информации о таких балансировщиках превышали пару секунд, что, очевидно, раздражало пользователей и администраторов. В борьбе с этим багом мне удалось увеличить скорость ответа в два раза за счет уменьшения обхода графа.

Авторы основной ветки пошли дальше и предложили решение, которое давало существенный прирост в скорости ответа за счет отказа от использования промежуточной модели данных. Вместо нее они реализовали прямую связь между базой данных и моделями api.

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

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

Стоит отметить, что при переносе этого патча в предыдущую версию Octavia, где еще не выполнен переход на SQLAlchemy 2, могут возникнуть конфликты.

И все‑таки настоятельно советую всем, кто устал от медленных GET-запросов, попробовать применить этот патч или обновить Octavia до последней версии.

Снижайте расходы до 80 процентов в облачных серверах Selectel

Подключите прерываемые ВМ и функцию «Заморозка» в панели управления.

Подробнее →

Обновления

Legacy

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

• Удалена поддержка Python 3.10, теперь минимально поддерживаемая версия — 3.11. Администраторам облака, которые использовали старый Python для запуска сервисов Octavia, при переходе на 2026.2 придется апдейтнуть его либо отдельно, либо вместе с операционной системой.

• Равным образом удалена неиспользуемая опция octavia_plugins. Подобные правки полезны, потому что они уменьшают когнитивную нагрузку на инженеров, только изучающих инициатива. Обычно, если в коде есть опция, то подразумевается, что она для чего-то нужна — как следствие, специалистам приходится тратить время на выяснение того, не является ли она неудаленным техническим долгом.

Новая версия Taskflow 

В этом релизе обновлена библиотека Taskflow. Для тех, кто в первый раз о ней слышит, она применяется в логике механизма jobboard для решения проблемы балансировщиков, повисших в статусе PENDING_* (детальнее можно почитать в документации OpenStack).

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

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

Другие изменения

Исправлена сбой^[3], из‑за которой блокировалось создание балансировщика при проверке SSL‑сертификатов между octavia-worker и амфорой. Задача была связана с Python 3.13 и опцией VERIFY_X509_STRICT, включенной по умолчанию. Теперь при генерации сертификатов автоматически добавляются расширения: Subject Key Identifier (SKI) и Authority Key Identifier (AKI). Для обновления существующих ключей потребуется выполнить пересоздание амфоры балансировщика (failover) или ждать автоматической ротации средствами сервиса octavia-housekeeping.

В контексте исправления ошибки открытого порта для взаимодействия VRRP и HAProxy^[4] добавлена новая опция use_remote_group_for_lb_peer_ports. Суть проблемы в том, что правила безопасности у VRRP‑портов амфоры не запрещают доступ к ним с посторонних IP‑адресов.

Уязвимость не была критичной, так как в конфигурации keepalived явно указываются IP‑адреса для VRRP‑связи. Тем не менее для повышения защищенности добавлена новая опция, которая по умолчанию включена. В этом случае используется алгоритм Remote Security Groups для ограничения доступа к VRRP: посещаемость разрешается только с амфор того же балансировщика. Опцию можно отключить, чтобы вернуть прежнее поведение — это может быть полезно для развертываний в облаке, где опция Remote Security Groups не работает.

Исправления, на которые стоит обратить внимание 

Как многие знают, с развитием LLM значительно выросло количество отчетов об уязвимостях. Инициатива Octavia не стал исключением: новые записи CVE (Common Vulnerabilities and Exposures) постоянно встречаются в том или ином релизе.

В версии 2026.2 зарегистрировали одну уязвимость, касающуюся политик QoS^[5]. Она достаточно неприятная, хотя не самая критичная по мнению возможных последствий. Тем не менее, исправление настоятельно рекомендуется перенести в текущую инфраструктуру, если обновление до новой версии Octavia пока не планируется. В официальных репозиториях доступны патчи вплоть до версии 2025.1, но исправление можно адаптировать и для более ранних версий, так как оно затрагивает исключительно логику api. 

Отдельного внимания заслуживают две другие ошибки, связанные с параметрами tls_ciphers^[6] и политиками уровня L7^[7] (redirect_url и redirect_prefix).

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

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

Важно отметить и ряд изменений, связанных с отчетами об ошибках^[8], которые направлены на усовершенствование совместимости с Python 3.14. Это свидетельствует о поддержке современного технологического стека в проекте, что позволяет пользователям применять свежие версии дистрибутивов с новыми версиями Python.

Заключение

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

Инженерам, поддерживающим старую версию без планов на немедленное обновление, можно однозначно рекомендовать применение патчей с исправлением проблем безопасности. Равным образом при наличии технической возможности стоит внедрить оптимизацию для ускорения работы GET‑запросов к api.