Tech Sketch Bucket of Technical Chips by TIS Inc.

OpenStack Upstream Trainingに参加してきました

Pocket

2/3(火)-4(水)にOpenStack Days Tokyo 2015が開催されました。今回、特別企画として実施されたUpstream Trainingに参加することができたので、その様子を紹介します。

OpenStack Upstream Trainingとは

OpenStackの開発コミュニティは、バグの管理やレビューシステムがしっかりと整備されており、世界中のコントリビュータが連携して開発に取り組めるようになっています。 その一方で、いきなりPull Requestをなげるようなやり方は認められておらず、きちんとした手順を踏まないと追加機能やバグ修正を取り込んでもらうことはできません。 そのため、OpenStackにコントリビュートするには、コミュニティの開発スタイルやレビューシステムの使い方を理解する必要があります。

OpenStack Upstream Trainingは、OpenStackコミュニティの開発者となるための実践的なトレーニングです。 受講者は、コミュニティの開発スタイルを学び、トレーニング後1ヶ月程度をかけて実際にOpenStackのバグを修正し、パッチがマージされることを目指します。

OpenStack Upstream Trainingは、2014年5月のアトランタサミットや2014年11月のパリサミットで実施されたほか、日本でも2014年10月に日本OpenStackユーザ会のメンバーを中心に実施されています。 今回のトレーニングは、ユーザ会のメンバーに限らず、OpenStack Daysの参加者から広く募集されました。

トレーニングの内容

日本版のトレーニングは、Foundation主催のトレーニングと同じ内容で、以下のようなことを実施します。 基本的には座学ですが、適宜演習を行います。

OpenStackコミュニティについて学ぶ

  • OpenStack FoundationやTechnical Committeeの役割について
  • リリースサイクルやコミュニティのエコシステムについて
  • Design SummitsやIRCミーティングについて

コントリビューションのワークフローについて学ぶ

  • devstackによる環境構築
  • バグ報告、レビューシステムの使い方
  • sandbox環境でのワークフロー演習

OSSへのコントリビューションについて考える

  • コミュニティとの付き合い方
  • レゴブロックを使ったアジャイル開発体験
  • 振り返り

レゴブロックを使ったアジャイル開発体験

OpenStack Upstream Trainingには、アジャイル開発のプロセスとコミュニティのエコシステムを理解するために、レゴブロックを使った体験プログラムがあります。 受講者はいくつかのカンパニーに分かれて、アップストリーム(レゴタウンの市長、レビュアー)とやりとりしながら、レゴタウンを大きくしていきます。

体験プログラムでは、以下の各フェーズを1サイクルとして実施し、合計で4サイクル実施します。

計画フェーズ(5分)

  • 各カンパニーがバックログの中から、建てたい建築物を選択します(自分たちで新しい建築物をバックログに追加することも可)。
  • 作る建築物を決めたら、どのように実装するかメンバーで相談します。

実装フェーズ(10分)

  • レゴブロックを使って建築物を作ります。

レビュー(10分)

  • アップストリームから建築物についてレビューを受けます。
  • 特長などをプレゼンしてレゴタウンにマージされるよう努めます。
  • レビューを通過すると、建築物がレゴタウンにマージされます。
  • レビューを通過できなかった建築物は次のサイクルに持ち越され、マージされるよう改善していきます。

下記の写真は作成した病院と展望タワーです。展望タワーはレビューで高さが足りないと指摘され、脚を伸ばす、第2展望台を作るなどの改善案が出されました。

lego

レビューを通過した建築物はレゴタウンにマージされます。レゴタウンの様子を見て次に建てる建築物をバックログに追加していきます。 建築物だけでなく景観を良くするための区画整備なども提案されました。 完成したレゴタウンはイベント会場で展示されました。

lego-town

OpenStackのバグ修正に挑戦

受講者は、上記のトレーニングと並行して、実際のOpenStackのバグ修正に挑戦します。

開発環境の準備

OpenStackコミュニティのレビューシステムを利用するためには、以下のアカウントを作成する必要があります。 詳しい手順は Developer's Guide に記載されています。

修正するバグの選択

修正するバグはlaunchpadに既に報告されているバグから選択しても良いですし、自分が見つけたバグを新規に報告して修正しても構いません。 例えば、報告済みのNovaのバグは https://bugs.launchpad.net/nova から確認できます。

バグを選択する際の目安として、メンターから以下のようなアドバイスがなされました。

  • 必ずAssigneeなし(Assigned toがUnassigned)のものを選ぶ
  • StatusがNew、Confirmed、Triagedのものから選ぶ
  • バグの内容が具体的に書かれているもの、再現しやすいものを選ぶ
  • Tagsにlow-hanging-fruitと付いているものが初心者向きとされている
    • ただし、影響が少ないバグはレビューが後回しになる可能性もある
  • ImportanceがLow、Wishlist、Undecidedのものから選んでもよい
    • ただし、こちらもレビューされにくい可能性がある
  • 自分が使っているコンポーネント、興味のあるコンポーネントのバグを選ぶ

修正するバグを選択したら、バグの担当者に自分を登録して、各自でパッチを作成します。 バグの選び方、レビューシステムの使い方、コメントの書き方やマナーなどは、メンターが随時相談に乗ってくれます。

レビューシステムを使った開発のワークフロー

バグを選択したら、実際に修正を行っていきます。 Gerritを使った開発のワークフローは以下のようになります。

code_review http://docs.openstack.org/infra/manual/developers.html

ローカル環境でバグを修正したら、 git-review というgitのサブコマンドを利用して、コミットした内容をGerritに送信します。 コミットが送信されると、自動的にJenkinsでテストが実施されます。 また、Gerritから返されたURLにアクセスすると、コードの修正箇所やJenkinsの実行結果を確認することができます。

コミット内容をGerritに登録したら、レビューを受けながらコードを修正していきます。 レビューコメントを書いたり評価をつけたりすることはどの開発者でも可能ですが、マージされるためにはコアデベロッパーのレビューを受ける必要があります。 なかなかコメントや評価が付かない場合は、Gerritで任意のレビュアーを追加したり、IRCミーティングで声をかけるなどして、レビューを促すとよいでしょう。 最終的にコアデベロッパーの承認を受けると、コミットがMasterにマージされます。

おわりに

OpenStackコミュニティの開発スタイルは、最初は覚えることが多く、大変なように感じられます。 ですが、一度やり方が分かってしまえば、自動化されたレビューシステムや数多くの開発者のサポートを受けながら開発することができます。

私はまだレビューを受けて修正を続けている段階ですが、この記事を書いている時点ですでにパッチがマージされた受講者の方も何人かいます。 次期バージョンのリリース前になるとコアデベロッパーが忙しくなりレビューされにくくなってしまうため、それまでにマージされるよう頑張りたいと思います。

エンジニア採用中!私たちと一緒に働いてみませんか?