Всем привет! Меня зовут Крайнев Сергей, я работаю старшим бекэнд-разработчиком в Selectel. Поскольку в нашем публичном облаке используются компоненты OpenStack, мы следим за развитием основных веток этих проектов.
В конце сентября выходит новая версия под номером 2026.2. Заглядываем в примечания к выпуску и смотрим, что появилось нового.
Новый функционал
В этом разделе отмечены три изменения:
- ускорение обработки GET‑запросов для балансировщиков с большим числом ресурсов;
- новая конфигурационная опция
denylist_vip_networks; - изменение параметра архитектуры при сборке образа амфоры.
Рассмотрим каждое из них подробнее.
Сборка образа амфоры
При сборке образа амфоры можно указать опцию -a. Она характеризует, какой тип архитектуры будет использован при сборке итогового образа. Возможные значения: amd64, armhf, arm64, aarch64 и ppc64le.
Ранее по умолчанию применялась опция amd64, однако теперь эту логику изменили: при сборке задействуется архитектура той системы, где собирается образ.
Правка незначительная, однако тем, кто не указывал эту опцию явно, теперь придется это делать для предсказуемого поведения при сборке образа.
Новая опция denylist_vip_networks
Функционал предназначен скорее для администраторов облака, чем для конечных пользователей. Опцию можно задать в конфигурационном файле. Она принимает список идентификаторов сетей, которые нельзя использовать в качестве VIP‑адреса балансировщика.
Такой «черный список» пригодится при наличии общедоступной (разделяемой) сети, которую владельцы облака хотят скрыть при создании балансировщиков.
В подобных сценариях новый код легко перенести патчем в старые версии без полного обновления, потребуется лишь перезапуск сервисов. Важно, что включение denylist_vip_networks не повлияет на уже существующие сетевые соединения — доступ не получат только новые подключения.
Изменение логики API GET‑запросов
На мой взгляд, смена логики обработки запросов — наиболее интересное изменение в релизе. Оно нацелено на улучшение работы с крупными балансировщиками, которые часто создаются с помощью автоматизации Kubernetes и библиотеки gophercloud. Особенность таких балансировщиков заключается в том, что они могут содержать более 200 вложенных ресурсов — например, 40 листенеров, в каждом — по одному пулу с 40 серверами.
В оригинальном отчете об ошибке[1] упоминаются на порядок бо́льшие значения, однако проблема наблюдалась и на приведенном выше примере[2]. Запросы на получение информации о таких балансировщиках превышали пару секунд, что, очевидно, раздражало пользователей и администраторов. В борьбе с этим багом мне удалось увеличить скорость ответа в два раза за счет уменьшения обхода графа.
Разработчики основной ветки пошли дальше и предложили решение, которое давало существенный прирост в скорости ответа за счет отказа от использования промежуточной модели данных. Вместо нее они реализовали прямую связь между базой данных и моделями API.
В ходе этих правок был удален и мой небольшой фикс. Что ж, если предложенный подход дает лучшую производительность, то невелика потеря.
Мы пока не тестировали эти изменения в условиях нашего облака, но поставили их в план после ряда проверок.
Стоит отметить, что при переносе этого патча в предыдущую версию Octavia, где еще не выполнен переход на SQLAlchemy 2, могут возникнуть конфликты.
И все‑таки настоятельно советую всем, кто устал от медленных GET-запросов, попробовать применить этот патч или обновить Octavia до последней версии.
Обновления
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.
Ссылки
[1] Suboptimal performance on multiple API calls
[2] Octavia GET request for members in pool takes a lot of time on huge Loadbalancer
[3] Octavia Amphora server.pem missing Authority Key Identifier
[4] VRRP and HAProxy peer port open to 0.0.0.0/0
[5] Unauthorized QoS policy deletion lock
[6] Octavia Pool tls_ciphers Permits HAProxy Configuration Injection
[7] Octavia L7 redirect_url Permits HAProxy Configuration Injection
[8] octavia: Fix multiprocessing configuration inheritance with Python 3.14
