Наш коллега, Andy Grover, всерьез предлагает начать писать системное ПО на Rust.

Он мало того, что предлагает, так он уже начал его использовать. Например, он разрабатывает на Rust froyo, очередную систему хранения, основанную на devicemapper и LVM.

В GDB поддержка Rust уже есть, и теперь хорошо бы, чтобы язык появился в репозиториях Fedora, а то самому собирать как-то неинтересно.

Наши друзья из CoreOS официально представили новое распределенное хранилище - Torus (бублик, а не сбежавший из имперских каменоломень дикарь с молотком).

Вкратце, это написанный на golang фреймворк с плагинами, реализующими некие серверы для доступа к ресурсам, к которому прилагается управление по gRPC и которое использует etcd для синхронизации и хранения метаданных. Благодаря etcd с его проверенными кластеризационными возможностями можно было сфокусироваться на бизнес-логике, пока непонятно не в ущерб ли скорости? Пока реализован только NBD-сервер (наши коллеги давно используют такой подход, например, в nbdkit), но в процессе объектное хранилище, что понравится разработчикам облачных систем. Приложение является одновременно и библиотекой, как это принято в golang-сообществе, и управляется с помощью kubernetes. Коллеги-аналитики уже обсуждают проект на OpenNET.ru.

Многие наши друзья сразу же попросили прокомментировать анонс разработчика GlusterFS и CloudFS/HekaFS, инженера Red Hat и участника Fedora, Jeff Darcy, что он и сделал. Не все так однозначно, предостерегает Jeff. Он с разочарованием отмечает, что даже не обращая внимание на свойственный молодым проектам оптимизм в заявленных результатах, сильно разнящийся с достигнутыми результатами, нельзя не заметить сильный привкус маркетоидной лексики. Например, проект позиционирует себя, как альтернативу неким неназываемым старым системам, якобы разработанным для небольших кластеров из больших машин, хотя ни одно из популярных альтернативных решений, на самом деле не разрабатывалось в прицеле только на трех-узловой кластер из узлов по 64 процессора. GlusterFS, Ceph, Sheepdog (на который Torus очень похож архитектурно), все они разрабатывались для применения на больших кластерах.

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

Jeff делает вывод - в системе, или как минимум, в ее анонсе, нет ничего, что позволяло бы сделать вывод о какой-то там особенной применимости Torus для кластеров из контейнеров. Ни эффективных оверлейных систем, ни хитроумной дедупликации, ни multitenancy. То, что есть (NBD-сервер), это очень хорошо, но это не прорывная нанотехнологичная инновация.

Дальше Jeff все-таки обратил внимание, что анонсированные фичи проекта находятся в сильном несоответствии с уже достигнутым. Сообщается о скором добавлении шифрования, коррекции ошибок, и многих других нововведений, среди которых скорое добавление POSIX-интерфейса (якобы оно было, но работало плохо, и его убрали, чтобы спроектировать правильно и скоренько добавить в ближайшем будущем). Вообще-то добавить POSIX в распределенное блочное хранилище, это непросто. Например, в CephFS добавить его было совсем непросто.

Под конец Jeff раскритиковал особенно уж выглядящий глупым "бенчмарк" Torus.

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

Пакеты с WebKitGTK+ в Fedora серьезно затрясло. Сначала запланировали невзирая на поломки, срочно обновлять пакеты до самой последней версии, которую планируют поддерживать стабильной некоторое продолжительное время. А затем объявили, что WebKitGTK+ (пакеты webkitgtk и webkitgtk3) выбрасывают из Fedora 27, т.к. он дырявый, и не поддерживается. Вместо него предлагается перейти на WebKit2 (пакеты webkitgtk4). Причем WebKit для GTK2 поддерживаться больше не будет, т.е. приложение нужно портировать сначала на GTK3, затем на WebKit2.

Портирование на GTK3, это еще та веселая затея. Результат все равно не будет кросс-платформенным, и некоторые проекты решили переходить на Qt. С самим WebKit ситуация тоже интересная. Из Qt его выбросили в пользу Google Blink, но, вроде бы, проект QtWebKit может возродиться (благодаря нашим соотечественникам).

Внимательный коллега, Will Foster, заметил, что в известном сериале Silicon Valley один из действующих лиц, некто Richard Hendricks, использует CentOS 7 на макбуке.

Наш коллега, Dan Walsh, продолжает рассказывать о неочевидных вещах, связанных с SELinux.

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

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

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

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

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

Это архивная статья

Несмотря на недавний выход GnuTLS 3.5.0, наш коллега, Nikos Mavrogiannopoulos, был вынужден отвлечься, чтобы выкатить промежуточную версию - 3.4.13.

Оказалось, что если приложение, слинкованное с библиотекой, запущено с setuid, то появляется возможность перезаписать произвольный файл в системе. Напомним, что в systemd уже используются ambient capabilities, и наверное, в большинстве случаев запускать приложение с setuid уже необязательно. Конечно, эта функциональность неюниксвейна, работает только на Linux, и наверняка нарушает какой-нибудь стандарт 1987 года.

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

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

Это архивная статья

Наш коллега, Hans de Goede, недавно занявшийся разработкой открытого драйвера для NVIDIA, в сводобное время, для души, разрабатывает и драйверы для других видеокарт. На днях он выложил драйвер для USB-проекторов на базе чипсета GM12U320.

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

А вот инженер дружественной нам компании Collabora, Pekka Paalanen не добавил, а наоборот удалил код. В Weston больше нет поддержки бэкенда для Raspberry Pi.

На самом деле, это очень хорошо, т.к. удалили бэкенд, который работал напрямую с проприетарным драйвером, а уже довольно давно разрабатывается открытый драйвер для чипсета VC4, и как сообщают коллеги, он уже вполне хорошо работает на Raspberry Pi.

Ну и напоследок новость о компании Endless, разрабатывающей линейку компьютеров под управлением оригинальной ОС на базе GNOME 3. Так вот, они выложили в открытый доступ их операционку. Ну что, пусть будет.

Это архивная статья

System Message: ERROR/3 (<string>, line 8)

Error in "rubric" directive: no content permitted.

.. rubric:: Весь из себя Python
   :name: весь-из-себя-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 и дергают что-то еще…

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

Это архивная статья

Запустился новый ресурс - русифицированный Q&A-сервис на базе уже существовавшего ask.fedoraproject.org.

Чтобы задать вопрос и/или ответить, нужно зарегистрироваться.

Принимается авторизация с популярных социальных сетей, с одним досадным исключением - VK пока не поддерживается. Patches are welcome!