*

OpenStackコントリビューターへの道(OpenStack Advent Calendar 2014 12/12)

公開日: 最終更新日:2015/02/09  |  By  |  OpenStack, OSS

by Ikuo Kumagai (@kumagai19o)

この記事はOpenStack Advent Calendar 2014 12/12 の記事です。

あなたはOSSのプロジェクトの開発へ参加したことがありますか?恥ずかしながら私はOpenStackが初めてでした。この記事はそういったこれからOpenStackの開発に参加したいという方に向けて、私の最初のパッチ提出の状況を紹介するものです。(ちなみに12/12現在、レビュー進行中の状況です。まだmergeされるには至っていません。→2015/2/7にmergeされました。) きっかけは、先日のOpenStack Summit で Upstream Traininig に参加 (※)したことです。今回はまずコントリビュートのプロセスを知り、実際にソースがマージされることを第一の目的としています。

(※Upstream Trainingの詳細はこちらの記事が詳しいです。)

どうやってコントリビュートするのか

本記事では私がUpstream Trainingで取り組んだバグ修正の流れを中心に紹介します。個人的に経験したことをメインとしているので、これが全てとは思わないでください。より網羅的に知りたい場合は、公式WikiのHow_To_ContributeやUpstream Trainingのテキストを参照されることをおススメします。

かかる労力

OpenStackのプログラムを書いて提出するのは、github上でpull リクエストを出すように単純にはできません。幾つかのアカウントを作り、ライセンスに同意し、その機能やバグについてコミュニティ上で議論し、ソースレビューを通らなければなりません。しかし、なぜそういったプロセスが必要なのかは少し考えれば分かります。OpenStackは他に類を見ないくらい巨大なオープンソースプロジェクトなので、各自が自由に参加できるプロジェクトなのに、開発のスピードを失わず一定の品質を確保できているのは、参加プロセスが確立しているからこそです。

Upstream Trainingの前提条件には「プログラミングやコミュニティとの会話に週に8時間を割くこと(Having at least 8 hours a week to dedicate to the project, be it through programming or through interacting with the community.)」とあります。時間がかかることは間違いありません。特に最初は色々な手続きを始めてするので、とっつきにくいです。だからこそUpstream Trainingなどで指南して貰えるのは非常に有効です。2015年のOpenStack Days Tokyo 2015では日本版Upstream Trainingが行われるとのことですので、私のようにOSSへの参加経験もなく、一人で始めるのが難しい場合は参加すると良いでしょう。

そして、コミュニティは常に開かれています。わからないことや困ったことはコミュニティの誰かに聞いたり、助けを求めることができます。

特典

直近の2つのリリースサイクル中に一度でもコアプロジェクトにコントリビューションした人はActive Technical Contributer(“ATC”) となります。() ATCはTechnical Commitee menberの選挙の投票権を持ち、デザインサミットを初めとするプロジェクトのミーティングに招待されることになります。半年毎に開催されるOpenStack Summitは有料ですが、ATCであればこれにも無料で参加できることになります。2015年10月には東京で OpenStack Summitが行われるので、今ATCになれば無料で参加できます。もちろん、ローカルで行ったbug fix をUpstreamに戻したり 自分の欲しい機能を Upstreamに実装するというのは、ATCでなければできないことです。上述のとおり、必要になってから始めると言うのもなかなか大変なので機会を見つけて予めATCとなっておくのが良いと思います。

コミュニケーションの方法

今回やってみて、コントリビューションする上で一番重要なのはプログラムを書くことではなく、適切にコミュニケーションを取ることだと感じました。連絡を取る手段には以下のようなものがあります。

  • 英語
    以下ツールを使ったコミュニケーションは全て英語です。ただ、IRC以外はリアルタイム性を求められないので翻訳サイトなどを駆使すれば何とかなります。そして英語が流暢であるに越したことはありませんが、出来ないからといって遠慮してはいけません。Upstream Trainingでは 英語を母語としない人とのコミュニケーションもトレーニングの一環だと教えられます。
  • IRC
    freenodeのIRC上にたくさんのチャネルが開かれています。Webクライアントで参加するのも良いし好きなIRCクライアントを使っても良いのでここで話をすることができます。Upstream TrainingではZNCを進められました。(※きちんと話をするのであればIRCクライアントソフトを使いましょう。私はUpstreamTrainingのメンタリングセッションをWebクライアントでして色々不都合がありました。)

    freenode_chat

    Limechatを使用した接続

  • メーリングリスト
    メーリングリストも複数あります。開発のために入るならとりあえずopenstack-dev は外せないところです。

    メールは後から検索することも可能

    メールは後から検索することも可能

  • Launchpad
    バグトラッキングやブループリントはここで行います。個々のバグについてコメントで意見を交換することができます。

    launchpad

    launchpad

  • Gerrit Review 
    パッチの提出後、修正箇所へのコメントなどはここで行います。
    gerrit

技術的な前提条件

当然のことながらプログラムを書いてテストする環境を自分で整えられることが必要となります。ドキュメントのコントリビューションもありますので、その場合はプログラムは書けなくてもよいと思います。

  • GitもしくはGithubの基本的な操作を理解していること
  • OpenStackのテスト環境を作れること(DevStack Quickstart)
  • プログラムが書けること(Pythonであればなおよし)

コントリビューションに至る手順

それではバグ修正を例にした一連の流れを私のケースを交えながら紹介します。

  • バグを選ぶ
    Launchpad上に挙げられたOpenStackのバグから、自分に適したバグを選定します。何はともあれATC(ActiveTechnicalContributer)になることだけが目的ならば扱いやすいとタグ付けされているバグから選ぶと良いとされています。実際にはここからadvanced searchを使って誰もアサインされてないもの、かつ自分の担当しようとするプロジェクトなど、検索条件を指定して選択することになると思います。

    advanced search

    advanced search

  • アカウントを用意する
    バグを自分にアサインするために、Ubuntu Oneのアカウントを作ります。Launchpadの右上のリンクからたどれば自然とアカウント作成画面に進みます。

    アカウント登録

    アカウント登録

  • バグを自分にアサインする
    このバグを自分が担当すると宣言するため、アサインします。以後自分の責任となりますので、よく考えて不明な点などは予めコメント欄で確認するなどしてからアサインしてください。

    バグのアサイン

    バグのアサイン

  •  バグの原因を突き止める
    バグの原因には直接の原因とそれが作りこまれた原因というのがあるかと思います。バグの原因と発生した経緯を抑えて修正した方が望ましいでしょう。

    • 直接の原因を調べる
      • 環境を作って再現する
        DevStackなどで構築したテスト環境でプログラムのどこが問題なのかを調べます。DevStackの実行環境であれば/opt/stack以下に実行されているソースがあるので、そこのソースを必要に応じて書き換えてみるなどしながら問題を再現、修正の確認をしましょう。
      • ソースコードを調べて必要があれば質問する。
        OpenStackのソースはGithub上にもあるのでWeb上で確認することができます。IRCやMLで議論したりする場合にはWeb上で確認できた方が便利です。
    • バグの作りこまれた経緯を調べる
      コミットログを調べ、不審な点があればlaunchpadのコメントに残したり、MLに質問したりしましょう。私の担当したバグではそのバグを含む機能が作りこまれた際に議論がほとんど行われていないという状況がありました。これをUpstreamTrainingのメンターに相談したところ、Launchpadのコメントに残してくれました。なお、その上でメンターからはもっとWeb上で誰かと議論すべきとアドバイスを受けました。
  • プログラムを修正する
    修正は小さく。関連する問題があるようならLaunchpadにバグをあげましょう。私のケースでは問題の修正箇所は1行にして新たに1件のバグを上げました。
  • 単体テストの実行
    修正した箇所は必ずテストをしましょう。単体テストの方法はプロジェクトごとに記載があるとおもいます。python-novaclientではtoxで実行できました。また単体テストではコードスタイルもチェックされます。必ず単体テストが通ってからレビューにかけましょう。
  • gerrit アカウントの発行
    レビューのためのGerritのアカウントはLaunchpadのアカウントとは異なるので改めて登録しましょう。※認証はUbuntuOneでできるのでGerrit上でログインはすぐに出来ます。
    ログインが済んだら右上のアカウントのリンクからSettingページに行き、以下を設定します。
    gerrit_setting

    • Eメールアドレス
      git コミットユーザとの突合せはメールアドレスで行うので一致するようにします。
    • UserID
      Gerrit上で表示されるユーザのアカウントです。
    • SSH public key
      ローカル開発環境からGerritにソースを上げる際のSSH公開鍵を登録します。
    • CLA(Contributor License Agreement)
      OpenStack プロジェクトのライセンスに同意します。
      ICLA
  • レビュー
    修正が済んだらコミットしreviewに出します。手順の詳細はこちら

    • ブランチを作成する
      butの場合は “bug/1234567 ” のように bug/BUG_NUMBER でブランチを切って作業します。BUG_NUMBERは launchpad上での番号です。
    • git のユーザと メールアドレスを設定する
      git configでユーザとメールアドレスを設定します。メールアドレスはGerritに登録したものと一致させてください。
    • コミットログを書く
      コミットログには作法があるので作法をよく読んで遵守してください。レビューアは非常にたくさんのレビューを抱えています。レビューアが一読して修正の必要性を理解できるようなコミットログを心がけましょう。(以下は私の例です。)

      commitlog

      コミットログ例

    • git review コマンドを実行する
    • Webで状況を確認する
      git reviewとメールが届きます。
      welcome_newcontributor続いてJenkinsの自動テストが実行されるので結果を待ちましょう。小一時間ほどかかります。必要であればテストされている状況も確認できます。
      zuul自分のレビュー中のリストは https://review.openstack.org/#/q/owner:<自分のgeriitアカウント>+status:open,n,z とすることで一覧を見ることができます。
      review_list
    • 指摘を受けたら議論し、修正する場合は再度パッチをあげる
      もし、指摘を受けた箇所を修正する場合は、レビューのステータスをwork in progressに変更します。こうすることで無駄にレビューされることを防ぎましょう。

      review

      review ボタンを押す

      workinprogress

      ステータスを変更する

まとめ

以上、少し長くなりましたがコントリビューションのプロセスをご紹介しました。UpstreamTrainingを受けて重要だと思った点を一点上げるとすれば、常にコミュニケーションを心がけることだと思います。私も初心者なので間違っている点などがあればご指摘ください。

関連記事

no image

Grizzlyの新機能(2) SLO ~ Swiftによるオブジェクトストレージシステムの構築(10)

by You Yamagata 2013.06.10 (Swift関連の記事の一覧は 

記事を読む

no image

CLIによるSwiftへのアクセス(後編) ~ Swiftによるオブジェクトストレージシステムの構築(4)

by yamagata 2013/2/7(Swift関連の記事の一覧はこちらをご覧ください)前回の

記事を読む

Rally-Actions

OpenStack Rally入門

RallyはOpenStackのプロジェクトの一つです。OpenStackのベンチマークツールと簡単

記事を読む

docker_all

OpenStack Summit in Paris (Day3)

by Ikuo Kumagai (@kumagai19o) 少し遅れましたがOpenStack S

記事を読む

no image

Swift 1.11.0 CHANGELOG の翻訳

by You Yamagata 2013.1.23(Swift関連の記事の一覧は インデッ

記事を読む

image

OpenStack Summit Portland Quick レポート

by hasegawa 2013.04.172013年4月15日〜18日にかけて米国のオレゴン州ポー

記事を読む

welcome

OpenStack Summit in Paris (Day1)

by Ikuo Kumagai (@kumagai19o)   こんに

記事を読む

no image

構成管理ツール「Ansible」のインストールと使用方法

ビットアイル総合研究所の田波です。 今回は構成管理ツール「Ansible」のインストール方法と

記事を読む

summittokyo

OpenStack Summit Tokyoのセッションへの投票をお願いします。

OpenStack Summit Tokyo のセッションへの投票が行われています。 弊研究所でも

記事を読む

no image

Nova Availability Zone と Cinder Availability Zone

OpenStack 担当 石川です。 実際に自分が使うか使わないかは置いておき、気になったオプ

記事を読む

no image

ビットアイル総合研究所は、クラウド技術に関する調査&研究を通して、社会と会社に寄与していくことを目的に、ビットアイル・エクイニクスの企業内研究所として2011年8月に設立されました。

openstack-figure1-2x
COHO DataStream のCinder連携

OpenStack Cinder のストレージバックエンドとしてはCe

blog-ocata
Jujuで Ocataを含む様々なバージョンのOpenStack をデプロイする方法

祝OpenStack Ocata リリース!! ということで、早速デプ

newton
Juju Manual Cloud で OpenStack 環境構築

本当にご無沙汰しております。 この投稿はOpenStack Adve

top
HACK! THE Juju/MAAS

6/8~6/10まで幕張メッセで開催されたInterop 2016。皆

dpdk
OpenStack OVS VXLAN ネットワークの高速化

少し前の話になりますが、3月2日に開催された 日本仮想化技術株式会社様

→もっと見る

PAGE TOP ↑