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

В общем, Dan за последнее время написал серию постов, посвященных SELinux и контейнерам, из которых как минимум два особенно примечательны:

• Для чего SELinux блокирует доступ к сокету Docker?
• Как позволить Docker-контейнерам обмениваться сокетами без отключения SELinux (Dan добавил необходимый параметр в Docker).

Из смешного, Dan рассказал, как он написал скрипт в пять строчек на Bash и не мог заставить его работать. Бедолага потерял примерно час рабочего времени, прежде чем понял, что Bash-скрипт с подстановкой команд может выполняться сложнее, чем построчно, сверху вниз.

Кстати, в прошлом году отмечали 15-летие SELinux, так что в этом году отметим совершеннолетие!

Помните новость, что наш коллега, Tom Tromey, предложил на рассмотрение поддержку Rust в GDB? Так вот, включили, и поддержка Rust будет доступна в следующем большом релизе GDB. Как раз вовремя, чтобы начинать использовать Rust для разработки плугинов для GStreamer.

К сожалению, язык пока не доступен в Fedora. Что-то все застряло.

В корпоративном блоге компании "Мирантис" опубликовали первую часть интервью с с Александрой Федоровой о тестировании OpenStack:

Весь из себя Python

Реплика Александры Федоровой, руководителя команды CI (Москва, Россия).

От редакции

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

Вопрос, ответ на который мы подготовили сегодня, касается тестирования и звучит следующим образом:

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

Для первой беседы на тему тестирования мы пригласили Александру Федорову, руководителя команды CI из московского офиса нашей компании. И вот что она рассказала…

Виды тестирования, применяемые в OpenStack

OpenStack — это много разных Python-проектов. Каждый проект тестируется на нескольких уровнях. Если точнее — на четырех:

• unit-тесты (или модульные тесты),
• функциональные тесты,
• интеграционные тесты
• и системные тесты.

Начнем по порядку. Специфика OpenStack в том, что это набор из большого числа достаточно независимых проектов. У каждого проекта есть свой фреймворк для unit-тестов. Функциональные тесты так же, как unit-тесты, связаны с особенностями использования того или иного сервиса. Управляются и автоматизируются эти тесты, опять же, на уровне одного конкретного проекта. Для Python-кода при этом используется стандартный подход запуска кода в tox-окружении.

Интеграционные тесты позволяют протестировать совместную работу нескольких проектов. Для этого принято использовать так называемый Devstack — написанный на Bash фреймворк для деплоймента базового OpenStack-окружения. На развернутом окружении далее прогоняется Python-based Tempest framework, он и позволяет тестировать сценарии взаимодействия между разными сервисами экосистемы OpenStack. Например, для создания compute-ноды нужно авторизоваться в Keystone, получить базовый образ из Glance и IP-адрес из Neutron.

Длинные цепочки взаимодействия между сервисами тестируются в апстриме на девелоперском окружении (DevStack), с помощью Tempest.

Нет ли конкуренции между фреймворками Tempest и Rally внутри экосистемы OpenStack?

Нет, сейчас эти два проекта сотрудничают друг с другом. Rally отвечает за бенчмарк-тестирование (или проверку производительности системы) и нагрузочное тестирование. Tempest — это про сценарии, про логику взаимодействия между сервисами, а Rally — про нагрузку: что произойдет, если я “прогоню” этот сценарий 100500 раз? Сколько времени это займет? Часто тестировщики “гоняют” Rally поверх Tempest. Или используют Tempest как Rally-case.

Итак, модульные, функциональные и интеграционные тесты есть в апстриме. Остальное — фреймворки системных тестов.

Фреймворки системных тестов

Почему это специфично было для Fuel? Потому что Fuel — это сервис развертывания OpenStack, и мы тестируем не просто сервисы и их работу друг с другом, а проверяем полный цикл, от установки управляющей Fuel-ноды на «пустой» сервер, предоставления доступа к OpenStack Dashboard, проигрывания типичных сценариев работы с облаком, до апгрейда кластера. Еще тестируем отдельно много разнообразных сценариев установки.

В апстриме DevStack предполагает довольно однообразное базовое девелоперское развертывание OpenStack: на одной ноде разворачиваются все сервисы, каждый из которых получает собственную screen-сессию, где разработчик может интерактивно выполнять какие-то операции, смотреть лог или даже патчить код «наживую». Во Fuel поддерживается установка OpenStack в HA-режиме с несколькими контроллерами, с разнообразными конфигурациями сети. Это тестирование более «тяжелое» — базовый системный тест занимает около полутора часов на «стандартном» bare-metal сервере.

Для системных тестов опять используется фреймворк, основанный на Python, который состоит из двух частей: Fuel devops, который готовит окружение из 5-10 виртуальных машин, и Fuel QA — тестовый фреймворк на базе Proboscis, в котором, собственно, содержится вся логика тестовых сценариев и реализация работы с Fuel и OpenStack.

Человек готовится к собеседованию в Mirantis: что ему нужно знать о тестировании?

С моей точки зрения, у нас QA-процессы построены на многих взаимодействиях с низкоуровневыми вещами. Например, процесс создает виртуальные машины, делает запрос к низкоуровневому API, “ходит” по серверам… Это не чисто python-в-себе. Из него всегда есть выходы на какие-то системные или OpenStack-сервисы. То есть ты не можешь ограничиваться только знанием python-фреймворка, нужна хорошая база. Но основные принципы те же. Возьмем, например, nose test фреймворк: тест-кейсы, настройка начального окружения, реверт к стандартному окружению, зависимости… Но наполнение каждого из этих шагов может быть нестандартным для классической python-разработки, потому что всегда есть “хвосты” наружу, которые смотрят из Python и дергают что-то еще…

Продолжение следует!

Вышел systemd 230. Фич довольно много, например systemctl revert, которая удаляет пользовательские изменения к указанному systemd-юниту (напомним, трогать юниты в /usr/lib/systemd не надо, а надо добавлять изменения в /etc/systemd/), но среди них есть особенно интересная - поддержка Ambient Capabilities, про которые мы вам уже рассказывали. Теперь можно будет легко передавать необходимые привилегии процессу, запускаемому не от суперпользователя.

Новость уже обсуждается коллегами-аналитиками на OpenNET.ru.