Уже известный вам наш коллега, участник 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, а не аналоги.