Представители Docker на своем стенде на прошедшем недавно Red Hat Summit раздавали футболки с провокационным текстом:



Ушлые журналисты из TheRegister заметили, и постепенно начал разгораться скандал. Как многим показалось, таким образом представители Docker Inc. выражали неприязнь к тому, что Red Hat в проекте Atomic используют патченную версию Docker. Наш коллега, Dan Walsh, был вынужден написать пост с разъяснениями:

Версия Docker, используемая в Project Atomic, уже некоторое время содержит серию патчей, отсутствующих в апстрим. Каждый раз, когда мы добавляем патч, это добавляет нам работы по его поддержке, так что мы бы предпочти не добавлять никаких патчей. Мы всегда стремимся включать все наши патчи в апстрим, и делать это публично.

В этой заметке мы постараемся описать все патчи, которые у нас есть:

  • Объясним типы патчей.
  • Опишем сами патчи.
  • Приведем ссылки на обсуждения на GitHub и на PR.

Кое кто утверждает, что наш репозиторий Docker, это форк репозитория апстрим.

Что это значит - форк?

Я занимаюсь открытым ПО уже очень давно, и мое определение форка может быть устаревшим. Я полагаю, что форк, это враждебное действие, совершенной одной группой, чтобы заставить людей использовать и развивать их версию проекта, и игнорировать оригинальную. Например, LibreOffice форкнулся от OpenOffice, или ранее Xorg форкнулся от Xfree86.

Сейчас GitHub изменил значение форка. Если ПО разрабатывается на GitHub или аналогичной платформе, то каждый, кто хочет внести вклад, должен нажать кнопку fork и начать писать свои патчи. На момент написания этой заметки у Docker на GitHub есть 9860 форков, включая наш. Однако, по определению все пакеты в дистрибутиве, которые собраны с патчами, это форки. Red Hat поставляет ядро Linux, и я пока не слышал, чтобы это называли форком. Но если вы считаете, что любой проект, который поставляется с дистроспецифичными патчами, это форк, то и оно тоже форк.

Апстрим Docker даже основывается на том, что Ubuntu пропатчила AUFS патчами, которые никогда не были включены в апстрим. Т.к. RHEL и производные дистрибутивы не содержат этих патчей, то мы добавили поддержку бэкендов для Devicemapper, OverlayFS, и Btrfs, которые полностью поддерживаются апстримом ядра. Вот так должны работают дистрибутивы для серьезных задач: поставлять пакеты, собранные и сконфигурированные так, чтобы их можно было поддерживать долго.

В конце концов мы продолжаем следить за изменениями в апстриме Docker и делать регулярные ребэйзы наших патчей. Мы уверены, что это важное отличие - одновременно позволяя ПО различаться, и создавая сильные сообщества. Это непохоже на враждебный форк, который разделяет сообщества - мы все еще работаем над преемственностью с апстримом.

Как я могу узнать подробности о патчах к конкретной версии Docker?

Все наши патчи описаны в файле README.md в соответствующем бранче нашего репозитория Docker. Например, если вы хотите посмотреть на патчи к docker-1.12, то обратите внимание на бранч docker-1.12.

Затем вы можете посмотреть на страницу со списком патчей к Docker, где есть информация про эти патчи.

Какие типы патчей включает Project Atomic?

Вот краткое описание типов патчей, которые мы используем, и инструкция по поиску информации про конкретный патч.

Бэкпорты из апстрима

Апстрим Docker Project, как правило, исправляет ошибки в следующей версии Docker. Это значит, что если пользователь столкнулся с ошибкой в docker-1.11, и мы предложили исправление в апстрим, то патч будет включен лишь в бранч master, и скорее всего никогда не будет бэкпортирован в docker-1.11.

Т.к. Docker выпускается с бешеной скоростью, то они будут предлагать пользователям обновиться до docker-1.12, когда он выйдет. Это хорошо, если пользователь хочет быть на острие разработки, но в ряде случаев новая версия приносит новые ошибки.

Например, в docker-1.11 сервис docker был разделен на три части: демон docker, containerd, и runc. Мы не считаем, что это изменение стабильно, чтобы поставлять его корпоративным пользователям сразу, как оно выйдет, хотя в этой версии и было множество исправлений для ошибок в версии docker-1.10. Много пользователей желают лишь получать обновления с исправлением ошибок, и не хотят тестировать все ПО снова каждые пару месяцев.

Другая проблема с поддержкой стабильной ветки ПО с быстро изменяющимися зависимостями, это что разработчики стабильной ветки вынуждены тратить время на проверку того, что их продукт остается стабильным каждый раз при обновлении зависимости. Это дорогостоящий процесс, и как результат зависимости обновляются нечасто. Это приводит к тому, что мы выбираем (cherry-pick) изменения из апстрима Docker и поставляем эти изменения со старыми версиями, чтобы исправлять ошибки, не обновляя или добавляя зависимости. Тот же подход мы применили, чтобы добавить capabilities в ядро Linux, подход, доказавший свою ценность для пользователей.

Патчи предложенные в апстрим

Мы также добавляем патчи, которые, как мы знаем, пользователи требуют прямо сейчас, но они еще не были включены в апстрим. Каждый патч, который мы добавляем в репозиторий Project Atomic, также предлагается на включение в апстрим-репозиторий Docker.

Эти типы патчей остаются в репозитории Project Atomic либо недолго, пока их рассматривают в апстриме на включение, либо навсегда, если апстрим отвергает их. Если мы не согласны с апстримом Docker и полагаем, что наши пользователи нуждаются в этих патчах, мы продолжаем применять их. В некоторых случаях, мы разрабатываем альтернативные подходы, например плагины для авторизации.

Например, пользователи образов RHEL, не публикуют образы Docker на публичных сайтах. Мы хотим, чтобы был возможность защитить пользователей от случайного выкладывания образа на базе RHEL на Docker Hub, и поэтому мы сначала сделали патч, которые блокирует выкладывание образа. А когда появились плагины авторизации , то мы создали плагин для защиты пользователя от публикации контента из RHEL на публичных сайтах, типа Docker Hub, и нам перестал быть нужным тот наш патч.

Подробный список патчей

Хотите знать больше о конкретном патче? Вы можете найти список патчей на нашей странице патчей к Docker.

Наш коллега, Андрей Маркелов, сообщает в своем блоге, что его новая книга по подготовке к экзамену Certified OpenStack Administrator доступна для предзаказа!



Моя новая книга над которой я работал последние пол-года доступна для предварительного заказа на сайте издательства Apress.com. По плану она выходит 30 ноября 2016 года. Книга поможет подготовиться к экзамену Certified OpenStack Administrator от OpenStack Foundation. Также будет не бесполезна при подготовке к сертификации от Mirantis. Полное описание книги и оглавление - на сайте издательства.

Пришли новости, что Rackspace выкупили за 4.3 миллиарда долларов США. Как вы помните, слухи о покупке Rackspace ходили с 2014 года, и вот, наконец-то, они материализовались.

Будем надеяться, что это хорошие новости для наших товарищей, трудоустроенных в RackSpace.

Сформирована программа конференции systemd.conf 2016. Среди выступающих как представители крупных корпоративных пользователей systemd (Bosch, n:stack / StackHut, NixOS, Facebook, например), так и компаний-разработчиков (например, Red Hat, Endocode, ProFUSION, Pengutronix, CoreOS, Canonical, Kinvolk). Интересно, остались ли те, кто считает, что systemd "ненужно" и "закопать"?

После выявления проблем с производительностью и после включения и поспешного отключения kdbus в Fedora Rawhide, разработка была свернута в пользу совершенно нового проекта - bus1. И вот, наконец-то, анонсировали его первую публичную версию. Разработчики резко упростили реализуемый функционал перепозиционировав проект, как n-to-n шина сообщений с поддержкой multicast и unicast и с системой безопасности на базе capabilities. Это было бы аналогом Binder из Android, если бы тот умел multicast. Из-за поддержки multicast пришлось добавить функционал неизменности порядка сообщений, т.е. если сторона (или стороны) отправила пакет A, а затем B, то независимо от того, unicast это или multicast, адресат получит сначала A, затем B.

Neil Brown уже написал статью на LWN, под которой началось интересное обсуждение. Учитывая фиаско с kdbus, наверное не стоит ожидать быстрого включения функционала bus1 в дистрибутивы, но пока мы сохраняем осторожный оптимизм.

Ну и из смешного - в systemd включили systemd-mount. Напоминаем:

Если кто не в курсе, то идеи, что в systemd надо включить управление сетью, wpa_supplicant, минимальный shell, минимальный текстовый редактор (для работы с конфигами), монтирование, управление логинами, и пр. высказываются регулярно. Люди вокруг тут-же начинают шутить про emacs, а вот Lennart сразу-же задумывается и даже забывает про бокал пива в руке.

Довольно горячее обсуждение вызвала публикация о переосмыслении разделения процессорных архитектур, для которых собираются пакеты в Koji на первичные и вторичные. Сейчас разделение осуществляется на уровне сборки - Koji для secondary arch физически отделен. Предлагается объeдинить все работоспособные сборщики в одну точку входа. Сделать это предлагается постепенно - с Fedora 26 к имеющимся сборщикам для i686, x86_64, armv7hl добавится сборщик для aarch64, а с Fedora 27 добавятся сборщики для архитектур Power64 и s390.

Не все мэйнтейнеры обрадовались и поддержали предложение. Многие имеют негативные впечатления от тормозного сборщика для armv7hl (давным давно кто-то померял результаты сборки на физическом оборудовании для armv7hl, и в Qemu, запущенном на мощном Intel-процессоре, и оказалось, что в эмуляторе получается быстрее), и опасаются, что добавление новых сборщиков для систем, которыми пользуются десятки человек, сильно затруднит процесс сборки. Другие недовольны тем, что если предложение примут, то ошибки сборки на непопулярных архитектурах будут блокировать сборку и на популярных. Пока идет обсуждение, но скорее всего примут.

Масла в огонь подлил наш коллега Rich W.M. Jones, который с радостью объявил, что вовсю идет процесс пересборки Fedora для новой процессорной архитектуры - RISC-V. Для архитектуры, считай, не существует физического оборудования (надо покупать FPGA и заливать туда прошивку проприетарными утилитами, работающими только под Windoz, либо использовать Qemu), и его неосторожное высказывание, что он надеется сделать ее основной архитектурой сборки еще больше разозлило тех, кто не желает терпеть проблемы от непопулярных архитектур. Для RISC-V уже есть поддержка в ядре Linux, в GCC, и в Glibc, но в остальном еще работы много. Например, только начали добавлять поддержку RISC-V в RPM. Так что опасения народа довольно понятны.

Мы будем следить за развитием событий.

Сформирована программа конференции LibreOffice Conference 2016, которая состоится с 7 по 9 сентября 2016 года в Брно. Приезжайте, обсудим текущее состояние и тенденции развития офисного пакета и его аналогов.




Поздравляем коллег, работающих по соседству! Наконец-то им можно официально ходить в офисе в шортах и футболке.

Последние несколько лет мэйнтейнером gettext является наш коллега, инженер Red Hat и участник Fedora Project, Daiki Ueno. За это время в gettext были внесены важные улучшения, благодаря которым нет никакой нужды использовать конкурирующее решение - intltool, разрабатывающееся в Launchpad с помощью bzr. Наш коллега, Matthias Clasen, в своем блоге постарался рассказать о преимуществах gettext. Вкратце, это большое количество понимаемых форматов (*.desktop, файлы Gtkbuilder, *.appdata.xml, *.metainfo.xml), включение и использование переведенных строк, и удобство подключения новых XML-форматов к gettext.

Peter Hutterer объявил, что libinput окончательно завершен. У него закончился TODO-список. Эта библиотека будет основным источником ввода для Wayland, поэтому это очень важно. Fedora перешла на libinput, как основной драйвер для X11 начиная с Fedora 22 - таким образом будет достигнут бесшовный переход на Wayland. Недавно, кстати, выпустили Wayland Protocols 1.5 - набор дополнительных протоколов для Wayland, и среди изменений есть относящиеся к touchpad. Немного опасаемся за будущее Wayland. В XMPP идея о базовом функционале и дополнительных функциях, реализуемых в виде необязательных к следованию им XEP, привела к тому, что гарантированно работали только базовые функции, и от протокола массово начали отказываться большие вендоры в пользу самописных, более функциональных решений.

Постепенно набирает скорость Vulkan. Наш коллега, инженер Red Hat и участник Fedora и Debian, David Airlie, предложил первый вариант Vulkan-драйвера для некоторых видеокарт AMD.

Новости о systemd больше не пугают революционностью. Недавно systemd дорос до версии 231. Основная работа, судя по ChangeLog, идет в направлении контейнеров и systemd-networkd. Интересно, что и systemd, и wayland стали настолько хороши, что GNOME в Fedora 24 теперь использует их практически незаметно для пользователя (обратите внимание на строку 259, где располагается процесс с PID 2147). А ведь нам уже говорили, что systemd --user планировали переработать.

Наши друзья из Parallels / OpenVZ наконец-то выпустили седьмую версию своего флагманского продукта. В этой версии, что особенно примечательно, было принято решение использовать KVM вместо самописного проприетарного гипервизора. Из других фич - использование CRIU для живой миграции контейнеров, еще меньшая разница между ядрами OpenVZ и RHEL, и постепенный отказ от утилиты vzctl в пользу virsh или аналогичных решений. И особенно хочется отметить последовательную реализацию плана по открытию своих технологий и увеличению прозрачности процесса. Вы знали, что у OpenVZ есть аккаунт на GitHub?

Решения, разработанные в Parallels, разбираются и другими вендорами, например Red Hat, где CRIU доступен как "technology preview" начиная с RHEL 7.2. В RHEL версия уже старовата, но попробовать можно. К сожалению не всегда к инженерам Parallels прислушиваются внимательно. Например, разработчики Parallels нашли ошибку в ядре года три назад, но тогда никто особо не заинтересовался. А вот недавно, та ошибка внезапно привлекла всеобщее внимание, т.к. с помощью Docker, который как некоторые ошибочно считают мегабезопасен, ее можно использовать на некоторых хостингах контейнеров. Сразу бы так.

Один из наших коллег был вынужден использовать вот такой патч:

--14,-14,-14,-14,-14,-14,-14,-14, -14,-14,-14,-14,-14,-14,-14,-14,
--14,-14,-14,-14,-14,-14,-14,-14, -14,-14,-14,-14,-14,-14,-14,-14,
+(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14, (uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,
+(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14, (uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,(uint8)-14,


Не все так однозначно!

Страницы