Russian Fedora

cообщество русскоязычных участников
международного проекта Fedora

Контроль качества в Open Source: опыт проекта CRIU

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

Наш коллега из Parallels, Сергей Бронников, поделился опытом тестирования проекта CRIU. К сожалению, его статья опубликована на запрещенном в РФ сайте dou.ua, и может быть недоступна с устройств, где госцензуру РФ обходить непросто, т.е. телефоны, планшеты, смарт-ТВ. Поэтому, пока вы не настроили себе способ обхода госцензуры, вы можете прочитать эту статью у нас.

Контроль качества в Open Source: опыт проекта CRIU

image0CRIU (Checkpoint and Restore In Userspace) — это проект по разработке инструментария для ОС Linux, который позволяет сохранить состояние процесса или группы процессов в файлы на диске и позднее восстановить его, в том числе после перезагрузки системы или на другом сервере без разрыва уже установленных сетевых соединений. Один из основных сценариев использования CRIU — это живая миграция контейнеров между серверами, но им применение проекта не ограничивается.

В 2012 году, когда Эндрю Мортон принял первую серию патчей для ядра Linux с целью поддержки C/R (Checkpoint/Restore) в пространстве пользователя, идея реализовать такую функциональность все ещё выглядела сумасшедшей.

А спустя четыре года проект CRIU получил признание и всё больше вызывает интерес к себе. До этого попытки реализовать C/R в Linux уже неоднократно предпринимались (DMTCP, BLCR, OpenVZ, CKPT и т.д.), но все они, к сожалению, не увенчались успехом. В то время как CRIU стал жизнеспособным проектом.

Я разрабатывал поддержку вывода в формате TestAnythingProtocol в систему запуска тестов CRIU и пока делал патч разобрался в том, как устроено тестирование CRIU. Своими знаниями хочу поделиться с читателями DOU.

Потребность в тестировании

На старте проекта всё было просто: трое разработчиков и небольшой набор функциональности. Но в ходе разработки количество разработчиков росло, появлялась новая функциональность, и перед нами встали следующие проблемы:
— Сделать запуск тестов простым и доступным любому разработчику, чтобы каждый при желании мог протестировать свои изменения;
— Количество комбинаций функциональности и поддерживаемых конфигураций стало расти экспоненциально, поэтому ручной запуск тестов стал отнимать много времени, и требовалась автоматизация задач;
— Время пользователей и разработчиков CRIU дорого, поэтому хотелось максимально покрывать функциональность тестами и исключить появление регрессий в новых версиях;
— Процесс тестирования новых изменений и результаты запуска тестов был закрытыми, хотелось сделать процесс прозрачным и открытым для сообщества;
— Процесс ревью перестал был достаточным критерием для принятия новых изменений, хотелось получать больше информации о качестве патчей до вливания в репозиторий.

Процесс разработки CRIU мало чем отличается от разработки ядра Linux. Все новые патчи проходят через список рассылки criu@openvz.org, где все новые изменения ревьюят разработчики из сообщества CRIU. Ревью позволяет выявить ошибки на самой ранней стадии, и поначалу ревью было единственным критерием для принятия новых изменений. В какой-то момент этого стало недостаточно, и теперь параллельно с ревью выполняется множество других проверок для новых изменений, которые влияют на решение, будут ли они приняты или нет: проверка компиляции, автоматический запуск тестов, измерение покрытия кода тестами, статический анализ кода. Для всего этого используются общедоступные инструменты, которые делают процесс проверки прозрачным и открытым для сообщества.

Все новые патчи из рассылки попадают в Patchwork, который автоматически запускает сборку проекта на всех поддерживаемых аппаратных платформах (x86_64, ARM, AArch64, PPC64le), чтобы убедиться, что новые изменения ее не сломали. Для этих целей мы используем сервис Travis CI. Вообще этот сервис ограничен использованием только одной архитектуры — x86_64, поэтому для остальных архитектур мы используем qemu-user-static внутри Docker контейнера.

image1

Хорошие рабочие тесты важны для любого более-менее сложного проекта.

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

Как устроен процесс тестирования

Для функционального регрессионного тестирования мы используем тесты из набора ZDTM (Zero DownTime Migration), которыми до этого успешно тестировали in-kernel реализацию C/R в OpenVZ. Каждый тест из этого набора запускается отдельно и проходит 3 стадии: подготовка окружения, «демонизация» и ожидание сигнала (который сигнализирует тесту о том, что пора проверять своё состояние), проверка результата.

Тесты условно разделены для две группы. Первая группа — это статические тесты, которые подготавливают некое постоянное окружение или состояние и «засыпают» в ожидании сигнала. Вторая группа — динамические тесты, которые постоянно меняют своё состояние и/или окружение (к примеру, пересылают данные через TCP соединение). Если в 2012 году набор тестов CRIU включал порядка 70 отдельных тестовых программ, то на сегодняшний день их количество увеличилось до 200.

Функциональные тесты мы запускаем на публичном Jenkins CI по расписанию и для каждого нового изменения, добавленного в репозиторий CRIU.

Польза запуска тестов для новых изменений несомненна — по нашей статистике, примерно каждое 10-е изменение ломает тесты.

image2

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

Да и, как известно, разработчики очень ленивы для регулярного прогона тестов, и даже если прогон тестов будет занимать 1 минуту, то они все равно не будут их запускать :)

Основная конфигурация для тестирования — запуск всего набора тестов на хосте, при котором каждая тестовая программа садится в определённую позу, процесс теста сохраняют и восстанавливают, а потом просят проверить, в той же позе он остался или нет.

Следующей по важности конфигурацией является проверка, что C/R не только работает, но и после checkpoint основной процесс не cломался. Поэтому каждый тест нужно прогнать ещё и в варианте, когда выполнена только первая часть (без восстановления) и проверить, что поза соблюдена. Это безресторный тест.

Восстановленный процесс может оказаться в той же позе, но не пригоден к повторному C/R. Так появляется ещё одна конфигурация — повторный C/R. Потом появляются конфигурации со снапшотами, C/R в окружении пространств имён, C/R с правами обычного пользователя, C/R с проверкой обратной совместимости, проверка успешного восстановления на BTRFS и NFS (потому что эти ФС имеют свои «особенности»).

Но помимо C/R для отдельных процессов, можно делать групповые C/R — сохранение группы процессов, когда все процессы находятся в одной позе и когда каждый процесс находится в своей позе.

Тестирование ядер. CRIU поддерживает несколько аппаратных архитектур, сейчас это x86_64, ARM, AArch64, PPC64le и на подходе i386. Суровая реальность заставляет нас тестировать еще и несколько версий ядер: последний официальный релиз ванильного ядра, ядро RHEL7 (которое базируется на 3.10) и ветку linux-next. Длительность тестов небольшая (2-10 мин), но если учесть количество комбинаций существующих сценариев и возможных конфигураций, то получается внушительная цифра.

Ядра из ветки linux-next мы тестируем, чтобы заранее находить и сообщать об изменениях, которые ломают наш проект. За время существования CRIU мы нашли порядка 20 багов, связанных с linux-next. Для тестирования linux-next нужно каждый раз использовать чистое тестовое окружение и для создания таких окружений очень удобно использовать облака для создания окружения по запросу. В нашем случае мы используем API одного из облачных провайдеров для создания ВМки, устанавливаем в нее ядро и запускаем тесты. Мы уверены, что не получим никаких «наводок» от предыдущих запусков.

image3

Fuzz тестирование. Функциональное тестирование гарантирует, что то, что работало раньше, будет работать и впредь, но оно не способно найти новых багов. Поэтому мы им не ограничиваемся и дополнительно используем fuzz тестирование. Не так активно как хотелось бы, но тем не менее. Например, тест maps007 создает random mappings и «трогает» эти участки памяти.

Error пути. Одними из плохо покрываемых участков кода являются error пути. Наиболее критические такие участки мы тестируем с помощью техники fault injection. Это метод тестирования, при котором предполагается искусственное внесение разного рода неисправностей для тестирования отказоустойчивости и, в частности, обработки исключений. Для такого вида тестирования ни одно существующее решение нам не подошло, и мы написали свой движокпрямо в коде CRIU. Часть тестов CRIU регулярно запускаем в режиме fault injection.

Статические анализаторы кода. В какой-то момент мы решили попробовать статические анализаторы кода. Начали с clang-analyzer и потом перешли на использование сервиса Coverity, который бесплатен для использования в открытых проектах.

До использования статических анализаторов мы переживали, что отчёты будут содержать много false positive багов, но на деле оказалось все наоборот — анализаторы находят баги, которые не выявляются тестами.

Теперь ни один релиз не обходится без проверки кода в Coverity.

Покрытия кода. В маленьких проектах никто не меряет покрытие кода регулярно, потому что оно и так известен мейнтейнеру проекта и со временем меняется незначительно. В основном покрытие измеряют, чтобы выявить участки кода, которые никогда не затрагиваются тестами, и понять, как их можно покрыть тестами или понять причины, почему существующие тесты не покрывают их. Разбирая результаты покрытия кода, мы не раз находили куски кода, которые не были покрыты тестами, хотя тесты на них были. Ужасно это понимать, когда сталкиваешься с этим. Для измерения покрытия мы используем стандартные утилиты gcov и lcov и вдобавок загружаем результаты в сервис Coveralls, чтобы проанализировать, какие именно строки в коде затрагиваются тестами.

К чему стремиться

В ходе решения стоявших перед нами проблем мы составили список того, какими должны быть тесты:
— К написанию тестов нужно подходить ответственно, потому что нет ничего хуже, чем искать баг в коде проекта, а найти его в коде теста;
— Код тестов должен быть таким же качественным, как и качество основного кода;
— Хорошие тесты получаются, когда вы их пишите до начала разработки фичи;
— Ценность тестов для разработчика увеличивается, если он их пишет и использует сам;
— Тесты нужно прогонять до того, как код попал в репозиторий, так как в этом случае понятно, кто должен исправлять выявленные проблемы;
— Плохие тесты хуже, чем их полное отсутствие. Потому что они дают ложное чувство того, что код работает.
— Много тестов не бывает, в проекте CRIU соотношение полезного кода к тестовому примерно 1.6 (48 KLOC vs 30 KLOC), и есть куда расти.

Language Server Protocol (LSP) в Eclipse

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

Microsoft опубликовала спецификацию протокола Language Server Protocol (LSP) в своей организации на GitHub. Это протокол для создания веб-ориентированных IDE для одиночной и коллективной разработки (и возможно в них программировать будет удобнее, чем в Vim). Наши коллеги из Red Hat и Eclipse Foundation добавляют поддержку в свои продукты - Red Hat объявил о разработке Javа-сервера LSP, а Eclipse Foundation (стратегический партнер Red Hat) объявил о поддержке LSP в Eclipse Che.

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

Как написать свой модуль для Ansible для REST API?

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

Наш коллега, Roland Wolters, написал хаутушку о том, что делать если среди всех многочисленных модулей Ansible еще нет поддержки некоего REST API сервиса. Оказалось, что ничего сложного.

image0Нет модуля Ansible? Напиши сам, ты же программист! Кстати, месяц назад Red Hat анонсировала выход Ansible 2.1, с поддержкой Windows и Docker.

Remy DeCausemaker покидает Fedora ради политической карьеры

Наш коллега, Remy DeCausemaker, объявил, что вынужден оставить пост "Fedora Community Action and Impact Lead" (что бы это ни значило) ради присоединения к команде Хиллари Клинтон. К сожалению, это потребует от него полной отдачи, и он не сможет совмещать. Многие наши коллеги участвуют в политике, как на профессиональном уровне, так и на любительском, поддерживая других политиков и политические организации, и мы всячески приветствуем решение Remy и желаем ему удачи! .. image:: https://communityblog.fedoraproject.org/wp-content/uploads/2016/03/Decause-and-Bean-Reunited.jpg

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

Unexpected indentation.
align: center
width: 70.0%

Ralph Bean (в кепке) и Remy DeCausemaker

Pulseaudio 9.0

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

Гентушник и бывший инженер Collabora, Arun Raghavan, объявил о выходе PulseAudio 9.0.

Среди заметных новинок - улучшение эхоподавления, о чем Arun уже подробно рассказывал в своем блоге, улучшение в маршрутизации звуковых потоков, и поддержка memfd вместо POSIX shared memory, о котором вы могли слышать. Все идет согласно плану, который Arun продемонстрировал публике еще в 2014 году. Новость уже обсуждают коллеги-аналитики на OpenNET.ru.

Вышел RFRemix 24

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

Доступен для загрузки RFRemix 24. На этот раз с небольшим запозданием, так как RPM Fusion всё-таки решили выложить свои пакеты для 24-й версии в updates-testing. Из-за этого пришлось в спешном порядке переделывать образы. Но будьте внимательны, пакеты в RPM Fusion Free Updates Testing не подписаны. Такая воль kwizard'а. Вообще для Fedora 24 сейчас есть testing репозиторий Free, а в качестве NonFree можно использовать репозиторий от Fedora 23.


gnome

Что у нас нового и старого

  • Для загрузки доступны две большие редакции RFRemix Server и Workstation (включая сетевые установки), а также Live-образы с различными рабочими столами;
  • Для поддержки мультимедии используется всё ещё RPM Fusion, у которого зашевелилась инфраструктура. Вообще вероятность что он будет жить намного выше, чем у проекта unitedrpms.github.io;
  • Для RPM Fusion используются немного измененные release-пакеты с подключением nonfree от Fedora 23 (для 24-й этого репозитория просто нет). Они должны обновиться на оригинальные автоматически, когда RPM Fusion будет полностью готов (что как раз и произошло в Fedora 23);
  • Многие пакеты из репозиториев Russian Fedora доступны из приложения GNOME Software (Программы);
  • Так же у нас пересобран freetype с subpixel rendering и subpixel hinting;
  • Fontconfig содержит патчи Ubuntu для LCD мониторов (в общем сломали шрифты как всегда);
  • Пакет fontconfig-infinality был выпилен по просьбам;
  • В образы Workstation (GNOME 3.20) по умолчанию для GNOME Shell (не для GTK) используется тема Korora из одноименного проекта. Также опционально добавлены темы Adapta и EvoPop для GTK и иконки EvoPop. Все отключается и в ключается в gnome-tweak-tool;
  • В репозитории содержится почти всевозможный набор мессенджеров: skype, viber, telegram-desktop. Также есть Chromium с pepper-flash, полный набор Opera и обычный flash-plugin.

Образы

Для загрузки доступны Live образы Workstation, KDE (Plasma 5), LXDE, XFCE, MATE и Cinnamon. DVD и netinstall образ RFRemix Server и netinstall образ RFRemix Workstation.

Куда сходить спросить, пожаловаться

Обновление

В принципе обновление с RFRemix 23 не должно составить проблем. Сперва полностью обновите текущую систему, а затем отдайте команду:

dnf --releasever=24 distro-sync --nogpgcheck

Планы на RFRemix 25

Так как RPM Fusion пока не оправдывает никаких надежд, у нас появилось огромное желание собрать всё нужно у себя. Одним словом сделать свой собственный велосипед. Эта идея не нова, но по крайней мере мы будем иметь всё что нужно и не зависеть от внешних репозиториев. Так что ждите RFRemix 25 осенью этого года.

Выпуск Fedora 24!

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

После нескольких переносов даты релиза, в последнее время ставших закономерностью, состоялся выпуск Fedora 24! Как обычно, обновились версии основных системных компонентов и прикладного ПО:

  • kernel 4.5
  • glibc 2.23
  • GCC 6.1
  • systemd 229
  • Mesa 11.2
  • NetworkManager 1.2
  • GNOME 3.20
  • Plasma desktop 5.6
  • LibreOffice 5.1

Основные общесистемные нововведения:

Из самодостаточных (несистемных) изменений можно отметить следующие:

Изменения, внедрение которых перенесено до последующих выпусков:

Также стоит отметить готовность репозиториев Russian Fedora для Fedora 24. Образы RFRemix 24 уже на подходе!

>>> `Загрузить <http://getfedora.org>`__
>>> `Обновление с предыдущих выпусков <https://fedoraproject.org/wiki/Upgrading>`__
>>> `Примечания к выпуску <https://docs.fedoraproject.org/en-US/Fedora/24/html/Release_Notes/>`__
>>> `Известные ошибки <https://fedoraproject.org/wiki/Common_F24_bugs>`__
>>> `Подробности <https://fedoramagazine.org/fedora-24-released/>`__

Самодостаточные пакеты

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

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

Недавний анонс Canonical содержал традиционные для компании натяжки и преувеличения, и был прочитан и пересказан с также традиционным энтузиазмом пользователей Ubuntu. Наши коллеги восприняли анонс с также традиционным недоумением.

http://risovach.ru/upload/2016/06/mem/kuau_116588860_orig_.jpg

К сожалению, только социально-организационными проблемами тут не обошлось. Коллеги-аналитики с различных Linux-ресурсов восприняли анонс, как "все пакеты устарели, и теперь разработчики ПО будут сами все упаковывать, игнорируя дурацкие требования мэйнтейнеров". Упаковка и доставка приложений разработчиками, это очень плохая ситуация, которой, к счастью, нет и не будет в Linux-мире. Которая, к сожалению, имеет место в Windoz, Maс OS X (как правильно пишется теперь?) и в мобильных операционках (когда запросы приложений порой удивляют, и ничего с этим не поделаешь). Один из мэйнтейнеров дистрибутива Arch Linux, Kyle Keen, предостерегает от передачи на откуп разработчикам всей инфраструктуры по распространению и установки пакетов (его пост уже обсуждают коллеги-аналитики на OpenNET.ru).

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

Разработчики GTK предложили новый план выпуска версий

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

Разработчики GTK, пытаясь вернуть популярность своему тулкиту среди разработчиков, предложили новый план по разработке новых версий тулкита. Он позволит выпускать версии чаще, и сохранять API-стабильность. Непонятно, что мешало им раньше выпускаться почаще, да и почему раньше не замечали, что радикальные смены API настолько тяжелы для разработчиков, что некоторые предпочти перейти на Qt.

Это пока не финальное решение, а некий план. Вкратце, предлагается раз в два года выпускать новую версию GTK, которая будет параллельно устанавливаема с другими версиями (как метко предположил коллега-аналитик, каждой программе будет своя версия GTK). После анонса версии, API будет нестабилен до выхода .6 релиза. Такие минорные версии планируется выпускать раз в полгода, т.е. стабилизация API в пределах мажорного релиза ожидается через 18 месяцев.

Посмотрим, что получится.