В славном городе Гонконге прямо сейчас проходит OpenStack Summit. На него поехало много наших коллег, товарищей и знакомых, и мы обязательно сообщим вам, как будут выложены видеозаписи и слайды их выступлений. Уже пошли интересные новости:

  • VMware продолжает вкладываться в OpenStack. Вчера, в Гонконге, они и Mirantis объявили о сотрудничестве. Интересно, что по статистике, гипервизор VMware в 2013 году вышел на второе место по популярности среди используемых для OpenStack платформ. Молодцы, VMware, что уж тут.
  • Red Hat анонсировала новую версию своего облачного продукта на базе OpenStack - RHEL OpenStack Platform 4.0.
  • Даже Cisco, и те теперь предлагают свою облачную платформу на базе OpenStack, включающую аппаратное обеспечение.


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

Разработчик Arch Linux, Tom Gundersen, в рассылке systemd-devel сегодня предложил первый вариант системного сервиса, networkd. Конфигурация сервиса производится с помощью ini-файлов, и сделана несовместимой ни с NetworkManager, ни с рекомендуемыми Red Hat способами настройки в /etc/sysconfig/network-scripts/*, ни с connman. Пока новшество вызвало смешанную реакцию.

Так как выпуск Fedora 20-Beta отложили ещё на семь дней, то на этой неделе будет выпущена RFRemix 19.1.

Также выложены слайды презентации

Dan Walsh объявил о выходе очередного релиза SELinux. В него вошли изменения, которые уже были доступны в Fedora и RHEL7, но в виде out-of-tree патчей - теперь большую часть включили в апстрим.

И еще одна новость. После двух лет разработки SELinux для Android, и после включения в официальную ветку начиная с версии 4.2, и в CyanogenMod в режиме permissive его переключили в режим enforcing в Android 4.4 KitKat. В то время, как некоторые юзеры все еще бездумно отключают его, т.к. он блокирует проприетарные приложения, работающие с ошибками, в Android он будет включен по умолчанию.

Контракт на решение от Red Hat, это еще и патентная защита. Например, не так давно, Red Hat защитила своего клиента, у которого вымогал деньги за т.н. "интеллектуальную собственность" рэкетир из Техаса. У чистых коммьюнити-дистрибутивов такого покрытия нет (зачастую коммерческой компании там вообще договариваться не то, что о юридической защите, но и о SLA, просто не с кем). Но, к сожалению, такого уровня поддержки порой нет и у некоторых "больших" компаний. Аккурат на Хелловин рэкетир Rockstar, подкармливаемый и науськиваемый хорошо известными Apple, Microsoft, RIM, Ericsson, Sony, наехал на группу производителей Android телефонов. Ситуацию усугубило то, что Google пытался перекупить патентный пул, который сейчас у Rockstar, и это теперь используют против него и партнеров - "знали, что нарушают, пытались уйти от ответственности". Это, кстати, одна из причин, почему патентные проблемы никогда не обсуждаются публично - любое обсуждение патентов будет трактоваться, как "знали, что нарушают, но продолжали, усугубляя вину", что выливается в еще бОльшие суммы дани рэкетирам. В этой связи интересно, что с позиции патентной защиты может предложить потенциальным покупателям одна компания, безуспешно пытающаяся вылезти на рынок телефонов со своим решением, основанным на Linux.

Вышел Docker 0.6.5. Но в Fedora уже docker версии 0.7.0, с патчами для работы с thin provisioning на основе device mapper.

Red Hat запустило новую программу, чтоб убеждать Enterprise-клиентов переходить на OpenStack.

Mairin Duffy написала отчет о первом собрании рабочей группы по созданию "Fedora Server". Пока решаются оргвопросы по работе группы.

Бессмысленный и злобный троллинг образованцами разработчиков OSS приносит свои плоды. Martin Gräßlin написал в своей ленте Google+, что за прошедший год он порывался несколько раз все бросить, в основном из-за ненависти фанбоев Ubuntu, которые отказывают ему в праве технической критики решений Canonical. Не все такие толстокожие, как Lennart Poettering, который забавляется, видя бессильные потоки ненависти в его адрес, продолжая походя "закапывать" все, что ему не нравится. Учтите это - мы же коммьюнити, а не свора собак, лающих друг на друга. Так или иначе, Martin прекращает поддерживать решения Ubuntu - общаться с участниками этого коммьюнити слишком неприятно для него. Пока непонятно, как это скажется на Kubuntu, но вряд ли хорошо. Интересно, что после GNOME разработчиков, у Canonical не заладилась дружба и с KDE-шниками. Это, наверное, заговор против Ubuntu, не иначе.

Red Hat в компании с Google и Oracle взялись доделывать сайт www.healthcare.com. Если кто не слышал, разработку этого важного для американцев сайта по неожиданному совпадению без конкурса поручили компании, высшим должностным лицом которой является Townes-Whitley - закадычная подруга Мишель Обамы по Принстонскому университету. Обе они были членами Ассоциации Темнокожих Выпускников Принстона. Потратили более полумиллиарда долларов, и ничего не заработало - прямо как в Skolkovo! Ну, раз редхатовцы с гуглем взялись, то теперь-то доделают.

Еще один отчет на LWN по выступлению с "2013 Kernel Summit". Tejun Heo, инженер Red Hat, рассказал о текущей ситуации с cgroups и о планах на будущее.

Нынешняя архитектура будет полностью переработана. Архитектура с множественной иерархичностью, когда процессы и даже отдельные их потоки могут находиться в разных иерархиях контроллеров, причем позволяется одновременно находиться в нескольких контроллерах, уходит. На замену ей идет строгая архитектура с единой иерархией и единым центром управления (сейчас это systemd). В ней процессы не смогут переносить свои потоки в "чужие" ветки управления, вместо этого они смогут управлять потоками в своей локальной ветке управления, правда только по CPU. Пока эта архитектура не доведена до завершения, и есть контроллеры, которые еще не принадлежат к вертикали власти cgroups, но их скоро переделают. Возможно будет некая очередная виртуальная файловая система, cgroupsfs, для управления.

На этом месте начались возражения и замечания. Уже известный вам инженер Red Hat, Peter Zijlstra, выразил свое беспокойство тем, что новая система управления ресурсами по потокам приложения не очень четко обрисована, и там еще много моментов, которые нужно проработать. Известный хулиган и матершинник, Linus Torvalds, был недоволен тем, что управление внутри процесса будет лишь по CPU, в то время, как есть люди, которым интересно управление потоками и по другим ресурсам.

В целом больше возражений не было, и начали обсуждать процесс перехода на новый интерфейс. Linus потребовал, чтоб старый многоиерархичный интерфейс сидел в ядре еще минимум 10 лет, пока не вымрут мамонты. Tejun подозрительно быстро, быстрее, чем стоило бы потратить на обдумывание, согласился. Можно предположить, что он надеется, что 10 лет использовать старый интерфейс никто не будет - даже Google, который изначально возражал против переделки cgroups, теперь сменил свое мнение.

Hugh Dickins, инженер Google, спросил, а что произойдет, если кто-то пришлет патч, расширяющий старую реализацию cgroups. Tejun ответил, что значимость изменения должна быть необычно высокой. Т.е. нет, не примем.

На LWN опубликовали рекап выступления Pavel Emelyanov из Parallels на "2013 Kernel Summit", - "Checkpoint/restart in user space".

Сначала Павел рассказал об истории CRIU. Затем, он попросил разработчиков новых фич ядра всегда добавлять механизм получения текущего состояния (приведя пример с таймерами, которые можно создавать и уничтожать, но нельзя получить текущее состояние, почему ему пришлось дорабатывать эту функциональность), и попросил не увлекаться глобальными идентификаторами в ядре, предпочитая им локальные (привязанные к процессам). Павел также рассказал о разрабатываемой функциональности CRIU - checkpoint/restore всех процессов системы, перезапуск ядра с сохранением памяти нетронутой, и возвращение процессов, используя "старую" память. Это должно работать очень быстро. Andrew Morton спросил, а можно ли написать приложение, которое принципиально невозможно зачекпойнтить/отресторить? Павел ответил, что пока да, например Unix-сокеты вызывают проблемы, но он работает над этим - разработчики systemd хотят использовать эту функциональность.

CRIU уже вовсю используется, между прочим. Разработчикам сообщили, что CRIU сумел сохранить и впоследствии восстановить 48-гигабайтное приложение.

Уже известный вам наш коллега, участник Fedora и член технического комитета OpenStack, Mark McLoughlin изложил свои соображения на тему, OpenStack и его базовые компоненты. Проблема, давно вставшая перед ведущими игроками, вкладывающимися в OpenStack, это то, какие компоненты вообще могут содержать в названии торговую марку OpenStack? Эта тема уже давно обсуждается на самом высшем уровне иерархии OpenStack Foundation (например, Rob Hirschfeld, участник совета директоров, написал серию статей по вопросу), и ее актуальность вероятно уже достигла высшей точки. Дело в том, что OpenStack, это платформа, на которой строят свои решения самые разные заинтересованные стороны. И растущая популярность платформы приводит к тому, что разные компоненты в рамках разных предложений могут быть изменены на аналоги, проапгрейжены или даунгрейжены на другие версии, к ним могут быть добавлены еще какие-то компоненты, в них могут быть внесены иные изменения, продиктованные бизнес-процессами. Будет ли то, что получится, все еще OpenStack или нет? Или даже так - сможет ли пользователь такого измененного решения смигрировать на решение другого вендора?

Rob в августе этого года написал список из десяти предложений, чтобы определить то, какие компоненты, могут содержать в названии "OpenStack". Mark зацепился за предложение, что "все компоненты из Core должны проходить все базовые тесты". Речь идет о минимальном наборе модулей, с которыми бы все базовые тесты отрабатывали успешно.

Mark опасается, что определение для сертифицированного OpenStack Cloud провайдера (если некий референсный набор внешних тестов отработает на инфраструктуре, то можно официально выдавать такому провайдеру подтверждение / сертификат соответствия) без должного обдумывания, механически переносится в определение области ключевых компонентов системы. Он считает, что тесты определяют лишь пригодность API для ряда типичных use cases, а за API могут быть совершенно иные компоненты, с разными версиями и даже реализациями. Это позволяет взглянуть на проблему с совершенно новой стороны - а зачем регламентировать набор ключевых компонентов вообще (OpenStack Core)? Почему бы не заняться вопросом определения границ OpenStack Compatible Cloud? Mark сомневается, что защита торговой марки тут поможет - пользователям нужна совместимость на уровне API больше, чем соответствие реализации покомпонентно, и для достижения совместимости по API облачные провайдеры точно будут менять различные компоненты, даже те, что сейчас кое-как подводят под определение "OpenStack Core".

Mark замечает, что провайдерам будет выгоднее заявлять о полной совместимости с OpenStack, чем о заявлении об использовании OpenStack Core, и он считает, что дальнейшее обсуждение списка ключевых компонент будет тупиковым путем. Он предлагает немедленно начать обсуждение определение "OpenStack Compatible Cloud", т.е. какой API должны предоставлять провайдеры, и обсудить, какие шаги предпринять, чтоб провайдеры, которые хотят быть совместимыми, использовали компоненты OpenStack, а не аналоги.

Работает он на базе Fedora, разумеется:

Страницы