[Перевод] Интервью с Монти Тэйлором, руководителем проекта непрерывной интеграции в OpenStack

Это второе интервью из нашей серии интервью с руководителями проектов OpenStack в блоге Mirantis. Наша цель — обучить более широкое сообщество технических специалистов и помочь людям понять, как они могут внести вклад в проект OpenStack и извлечь из него выгоду. Естественно, ниже изложена точка зрения интервьюируемого, а не компании Mirantis. Интервью публикуется с купюрами в связи с ограничением длины статьи.

Наше второе интервью – с Монти Тейлором, техническим руководителем проекта непрерывной интеграции OpenStack CI (Continuous Integration).

Mirantis: Пожалуйста, представьтесь.

Монти Тейлор: Я работаю в компании Hewlett Packard над проектом OpenStack, участвую в комиссии OpenStack Foundation Board и в комитете OpenStack Technical Committee и веду проект непрерывной интеграции и инфраструктуры OpenStack CI and Infrastructure Project.

Вопрос: Как вы начали работать с проектом OpenStack?

Ответ: Я работал в Rackspace, в команде, которая изначально подняла проект OpenStack. Я тут с самого начала. Вы до сих пор можете увидеть мое имя под некоторыми проектами в Launchpad, так как я помогал их создавать, а внести изменения в Launchpad нельзя.

Вопрос: Почему вы работаете с OpenStack?

Ответ: Я твердо верю в важность открытого облака и в то, что все будут постепенно двигаться к управляемым сервисам и облачным приложениям.

Вопрос: Какова ваша ответственность в роли руководителя проекта?

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

Вопрос: Можете ли вы объяснить, что такое непрерывная интеграция -Continuous Integration (CI)? Почему она так важна для OpenStack?

Ответ: Мы начали проект с идеи автоматического контроля за состоянием кода. Вместо того, чтобы назначать специального человека, ответственного за вливание нового кода в мастер-ветку, что является очень скучной задачей, мы реализовали это автоматически.

Один из аспектов нашей системы — запуск тестов на каждом загруженном изменении кода. После проверки и утверждения кода тесты проводятся снова, так как скорость разработки OpenStack настолько велика, что вы можете быть практически уверены, что проект, в котором вы планируете изменения, уже продвинулся с того времени как вы написали код. Таким образом, мы хотим убедиться, что ничего из того, что добавляется в код, не нарушит его актуальное состояние.

Сейчас у нас 800 разработчиков активно трудятся над проектом OpenStack. Если мы позволим кому-либо из них что-либо нарушить, этот один повлияет на остальные 799, что приведет к эффекту водопада. Все расстроятся, и никто не сможет действовать дальше, так как будут подчищать за остальными.

Поэтому наша работа важна для проекта OpenStack из соображений качества и скорости разработки.

Вопрос: Что по-настоящему уникально в проекте OpenStack CI по сравнению с другими системами непрерывной интеграции, как, например, Jenkins или Buildbot?

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

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

Джим Блэр, один из ключевых участников команды инфраструктуры, написал инструмент под названием Zuul, который, можно сказать, управляет встраиванием кода всего проекта. Также, он обеспечивает выполнение наших строгих требований к работоспособности. Он периодически отслеживает изменения в OpenStack, что удобнее всего. Предположим, вы хотите запустить 150 исправлений, и проверка каждого исправления занимает час, но у вас нет 150 часов в сутках. Zuul может корректным образом тестировать эти исправления параллельно.

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

Вопрос: Чего на данный момент достигло сообщество непрерывной интеграции (CI)?

Ответ: Всего четыре участника команды держат проект на своих плечах, и мы продолжаем выпускать релизы. Это великолепно.

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

Вопрос: Какие возможности предоставляет непрерывная интеграция в выпуске Havana?

Ответ: Сейчас мы работаем над выпуском исправлений в Jenkins и Zuul для большей масштабируемости. Мы встраиваем технологию под названием Gearman в эту смесь, что позволит нам иметь несколько мастер-веток в Jenkins – это то, чего нет ни у кого другого. Таким образом, у нас нет узкого места в плане масштабируемости единого мастера Jenkins.

Мы также начали поднимать Logstash, центральный агрегатор логов. Обычно получение данных для отладки теста после сбоя было проблемой.

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

Суть нашей работы составляет предоставление обратной связи разработчикам для продолжения гибкой работы без снижения требований к тому, что означает выпуск обновлений в OpenStack.

Вопрос: Вы говорили о максимальной демократизации инструментов OpenStack. Что это означает для вас?

Ответ: Мы должны максимально отойти от ситуации, когда один человек имеет слишком много власти или ответственности, и это важно не только для инструментов, но и для всего проекта OpenStack. Это не только из опасений получения слишком большого влияния. Хотя любой может прийти и исправить проблему, в основном проект ведут те же четыре человека. Это означает, что в проекте есть подстраховка.

Также это означает, что вам не нужно убеждать кого-то в приоритетности своей проблемы над остальными, что приводит к политическим играм. У вас пять человек, которым что-то надо, и у одного из них много друзей, поэтому все работают над проблемой этого человека. Если у всех равный доступ, этот человек может просто выполнить работу – без необходимости убеждать кого-либо другого, что работа стоит усилий.

В проекте OpenStack участвуют более 200 компаний. Если кто-то из них хочет делать больше тестов, например, на Solaris, я должен обеспечить им эту возможность, а не заставлять их убеждать меня, что это важно, и затем обучать меня. Это несправедливо как для меня, так и для них.

Вопрос: Кажется, что вам удалось достичь баланса между оптимизмом и реализмом в отношении людей.

Ответ: Да. Если бы не оптимизм, я бы не занимался совместной разработкой с другими людьми, потому что не был бы уверен, что у кого-либо есть дельные идеи. Одновременно вам нужно признать, что люди могут ошибаться. Я знаю, что постоянно ошибаюсь и хочу сделать какой-то инструмент, который отслеживал бы мои ошибки, чтобы я мог концентрироваться на своей задаче, а не на ошибках синтаксиса. Компьютеры могут поработать за меня.

Вопрос: Говоря с философской точки зрения, каково ваше видение проекта OpenStack?

Ответ: Интернет сам по себе выполняет отличную работу по распространению приложений со стандартным интерфейсом. Существует много веб-серверов, но с точки зрения потребителя они все работают одинаково. В плане облачных вычислений ситуация другая. Amazon, GoGrid, Rackspace, Cloud.com, возникают все эти различные облака, и все они хотят заниматься инновациями, что очень хорошо.

Есть положительная и отрицательная стороны этого. Положительная сторона – все они просто решают проблему, которую никто раньше не решал. Отрицательная – каждая из этих компаний хочет удержать клиента, по аналогии с Prodigy и CompuServe перед стандартизацией глобальной сети.

Я бы очень хотел, чтобы открытое облако было основано на OpenStack и даже более того, как недавно выразился один мой друг на Facebook: “Все, кто используют слово “облако” для описания распределенного приложения только в собственном ЦОД, неправильно понимают это слово. Они фактически говорят о кластере”. И я согласен с этим. Облако – это 50, 100, 1000 компаний, все работающие на OpenStack. Как потребитель я хочу просто пользоваться этим агрегированным облаком без необходимости переписывать свое приложение или даже без того, чтобы знать, что мое приложение запущено на пяти сетях различных провайдеров.

Вопрос: Что бы вы хотели, чтобы люди знали о постоянной интеграции (CI)?

Ответ: Я не уверен, что все знают, что это открытая система, в которую может влиться любой, и что мы с радостью примем любого и ждем всех.

Вопрос: как можно начать работу над проектом?

Ответ: Для начала у нас есть IRC-канал #OpenStack-Intra и мы ведем баг-трек на Launchpad. Лучше всего чуть пообщаться там и отслеживать ревизии кода, добавляя комментарии или обратную связь, таким образом понимая актуальные на данный момент вопросы.

Вопрос: Как вы думаете, изменил ли проект OpenStack проекты с открытым кодом вообще? И, если да, то как?

Ответ: Над проектом OpenStack работают одновременно много компаний и нам удалось при таких исходных условиях, когда участвуют несколько корпораций, добиться многого. Кажется, что это первый такой проект. Linux вовлек много корпораций, но это заняло у них много времени… IBM и все эти корпоративные участники не сразу включились. Это был долгий путь по привлечению людей в их свободное от работы время.

Никто не работает над OpenStack в свободное от работы время. Это коммерческий проект, требования к которому определяются требованиями бизнеса. В то же время все эти компании объединились без явного лидера. Как руководитель проекта CI я думаю, что мы помогаем менять видение людей в отношении использования открытого кода в тестовой среде с жесткой инфраструктурой, с управляемым состоянием кода и всеми остальными возможностями. Поэтому, я думаю, мы исследуем новые земли как технологически, так организационно.

Вопрос: Большое спасибо, Монти!

Ответ: Не за что.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends: 'You Say What You Like, Because They Like What You Say' - http://www.medialens.org/index.php/alerts/alert-archive/alerts-2013/731-you-say-what-you-like-because-they-like-what-you-say.html