Я бы в OpenStack пошел — пусть меня научат
Первое, что нужно очень хорошо понимать, приступая к работе в рамках OpenStack – это структуру проекта. Платформа OpenStack создается глобальным сообществом, в котором действуют различные группы ИТ-специалистов с разными профилями специализации. Проект состоит из нескольких связанных между собой подпроектов, в каждом из которых участвует определенное количество core-специалистов (попросту “коры” по-русски): они отвечают за общий профиль проекта, этапы развития, составление roadmap и принятие ключевых решений об изменениях. Наряду с ними в проектах работают “драйверы” – разработчики, задача которых – улучшение всех составляющих Openstack.
Предостережем от стереотипа, что в Openstack-проектах участвуют исключительно «в свободное от основной работы время». Статистика говорит, что топовыми контрибьюторами сегодня являются сотрудники таких крупных компаний, как IBM, HP, Intel, Huawei, Mirantis и т.д.. Подчеркну, что это именно full-time сотрудники, то есть компании специально выделяют им время для работы по Openstack-направлениям.
Далеко не у всех программистов есть время писать и заливать код, но Openstack-сообщество - это не только девелоперы, но и аналитики, тестировщики, создатели сопроводительной документации. Поэтому каждый ИТ-специалист, в соответствии со своей специализацией, может повлиять на развитие платформы и при этом самостоятельно определять свой вклад: сколько времени он готов посвящать Openstack и в какой области проекта работать. Даже review кода в свободное время сильно поможет сообществу в перспективе решения задач. Как с этим определиться? Посетить на портале сообщества openstack.org раздел How to contribute – там подробно расписано, каким образом можно посодействовать реализации текущих проектов. Но если вы заинтересованы во внесении существенного вклада в OpenStack-проекты, вот несколько советов по началу работы.
Первое и самое важное – определиться, к какому проекту вы хотите присоединиться. В этом помогут два ресурса: https://launchpad.net/openstack и http://www.openstack.org. Можно просто почитать, но для полного доступа к функционалу этих порталов потребуется зарегистрироваться.
Через «баги» к «фиксам»
Один из лучших способов начала работы над проектом – посмотреть существующие в нем «баги». Далее возможны два пути: предложить свои решения для их устранения или… обнаружить новые, сообщив о них через стандартную форму Report a bug на странице проекта в Launchpad и на порталах сообщества в соответствующих разделах.
Посмотрим, как это работает, на примере проекта Nova. Находим его на Laucnhpad,открываем вкладку «баги» и начинаем изучение предметной области. Все «баги» сведены в списки, а благодаря системе фильтров их можно выбирать, например, по разработчикам или предметным областям. С помощью фильтра «по разработчику» вы можете найти, кто из участников проекта занимается интересной вам областью разработки, и присоединиться к его работе, например, в качестве независимого тестера.
После этого нужно скачать код – это можно сделать с официальных репозиториев (http://git.openstack.org/cgit или GerritWorkflow). Далее переходим из мастер-ветки обсуждений в ветку с названием «баг-№*», где сосредоточена вся информация по «вашему», теперь уже, багу. На Launchpad есть обсуждение каждого бага, по которому можно узнать, работали ли над устранением данного бага или необходимо выполнить работу с нуля.
После того, как первый этап работы будет завершен, вашу правку необходимо залить на сервис Review.openstack.org для дальнейшего рассмотрения участниками сообщества. Это делается с помощью утилиты git review, после чего система подтверждает ваш аккаунт на openstack.org.
Если все ОК, то планируемое изменение заливается на портал и становится доступным для рассмотрения сообществу разработчиков. Участники ставят свои оценки – рядовые разработчики могут ставить их в разбросе от «+1» до «-1», у core-разработчиков разброс больше: от «+2» до «-2». Оценки суммируются, и выносится решение – дать ли предложенному изменению «зеленый свет», включить в основной мастер-линк или вернуть на доработку. Для положительного решения необходимо получить как минимум одну оценку «+2» от одного из core-разработчиков на review и «+1» в Workflow.
После этого происходит проверка сервисом continuous integration (CI) – Jenkins, который запускает тесты и прогоняет предложенную правку по функциональным и юнит-тестам, проверяет ее на производительность и совместимость и т.д. Если все в порядке – ставится еще один +1 «от Дженкинса», и исправление отправляется в мaster-ветку проекта на git.openstack.org и github.com.
Общение, общение и еще раз общение
Отметим, что даже с мнением самых авторитетных разработчиков хоть и необходимо считаться, но можно и поспорить. Причем если удастся доказать свою правоту, то предыдущая версия исправления будет заменена на вашу. Core-специалист - это тот, кто занимается проектом достаточно долго, тратит на него много времени, предложил много принятых сообществом изменений - словом, хорошо ориентируясь в «дорожной карте» развития проекта и более погружен в него.
Важно понимать, что предлагаемые изменения практически никогда не принимаются с первого раза. В ответ на предложенное изменение коллеги по цеху «с чувством, с толком, с расстановкой» напишут вам, что именно вы не учли, забыли, сделали неоптимально с точки зрения кода или интеграции и так далее. Поэтому очень важно при внесении первой очереди правок детально учесть все ранее указанное в пожеланиях, изучить историю изменений. На review могут появиться детальные разборы вашего кода. Учитывая, что там к нему могут оставлять пометки коры – крайне рекомендуется следовать указаниям. Можно (нужно) вступать в диалог и обсуждать все полученные указания, поясняя, что и почему вы готовы или не готовы принять.
По итогам полученных замечаний создается следующая версия изменений (patchset и вновь отправляется на оценку. Если на этот раз все ок, она получает «зеленый свет» на применение в дальнейшей практике сообщества. Итераций правок может быть довольно много, в зависимости от критичности и важности точного исполнения пожеланий. Скорость рассмотрения может быть невысокой в связи с огромным количеством подгружаемых изменений. Средний темп – 3-5 дней.
Повышению скорости рассмотрения помогает сообщение о готовности ваших изменений в IRC-канале. Это, кстати, важнейший аспект работы в Openstack: неформальное общение по рабочим вопросам в IRC-каналах (чатах): все профильные чаты начинаются с суффикса OpenStack и далее включают в себя название проекта – Watcher, Nova и т.д. Там можно предлагать новые «фичи» проекта, сообщать об ошибках, обсуждать новинки и т.д.
Чтобы быстрее войти в курс дела, крайне рекомендуется постоянно участвовать в обсуждениях и рабочих встречах по проекту. Важно не просто быть в онлайне, но активно предлагать свои оценки, проекты решений и т.д. Подобные IRC-митинги проводятся, как минимум, раз в неделю согласно программе (agenda), детали которой сообщаются предварительно на профильных сайтах. Как правило, это подведение итогов, планы, рассмотрение текущих багов, фиксов, review, плюс свободное общение. Обычно такая онлайн-встреча занимает около часа.
Александр Чадин, инженер департамента программных решений ООО «Сервионика» (ГК «Ай-Теко»).
Опубликовано 17.10.2016