20131212 Okinawa OpenDays OpenStack

OpenStack 開発体制とコントリビューションへのお誘い

Akihiro Motoki (NEC)Dec 12th, 2013

2013/12/12 Okinawa OpenDays 2013 1

自己紹介

• 元木顕弘 (@ritchey98)– NEC 情報・ナレッジ研究所– IPルータ、広域Ethernet装置、迷惑メールフィルタなどの開発をやっていました。

– ここ数年は、ネットワーク仮想化、OpenStack, OpenFlow 周りで活動しています。

• OpenStack Developer– Neutron and Horizon Core Developer– I18N (国際化) team

• Linux JM (日本語マニュアル) Project Maintainer


OpenStack Projects• Integrated Projects

– Nova, Swift (Austin, 2010/10)– Glance (Bexar, 2011/02)– Keystone, Horizon (Essex, 2012/04)– Cinder, Neutron (Quantum) (Folsom, 2012/09)– Ceilometer, Heat (Havana, 2013/10)– Trove (Database Service) (Icehouse, 2014/04)

• Programs (OpenStack を支える様々な活動)– Oslo (Common Libraries)– Infrastructure (CI)– Documentation– Quality Assurance (QA)– DevStack– Release Cycle Management– (I18N)


OpenStack Projects (Cont.)• Incubated Projects

– Ironic (Bare Metal)– Marconi (Queue Service)– Savanna (Data processing)– TripleO (Deployment) + Tuskar (Management)

• Related Projects– Taskflow (State management)– Designate (DNSaaS)– Mistral (task management, Workflow as a Service)– Murano (Application Catalog)– Manila (Shared File System Service)– Climate (Reservation)– Rally (Benchmark as a Service)– Solum (Make cloud service easier with DevOps)– Congress (Policy as a Service)– Barbican (Secure Storage, Management of Secrets)


まだまだあります

OpenStack を取り巻く状況

• OpenStack を中心としたエコシステムが急速に形成されつつある• クラウド基盤のデファクトと認められつつある

• クラウドデータセンタのみならず、幅広い業界で利用されるようになりつつある– キャリア・通信サービス、サービス事業– アカデミック、エンタープライズ

• オープンな開発体制– Vendor Neutral な OpenStack Foundation によるプロジェクト運営– 来るものは拒まずというオープンソース志向

• 機能単位に分割されたモジュラー構成• 抽象化された論理 API• ドライバー構造


相乗効果

コントリビュートするメリットは?• Public/Private Cloud Operator• System Integrator (SIer)

– IaaSの要件はかなり近い。自分だけで開発するよりもOSS で開発した方がメリット大きい• 機能追加、メンテナンス• もちろんコストはかかるが、全部自分達でするよりは小

– 派生バージョンを作成してしまうと、追従するだけでも大変本家にフィードバック

• Vendor– OpenStack と接続できることで商機の拡大

• 基本は、エコシステムにのっかるということ


いろいろなコントリビューション形態

• https://wiki.openstack.org/wiki/How_To_Contribute

• 開発者としての貢献方法はこのあと

• 開発者でなくてもいろいろあります– ドキュメント作成への参加– バグ報告 (ドキュメント、各プロジェクト)– ML での回答・助言 (general ML, operators ML)– ユーザーサーベイへの参加

• 利用状況、要望などの調査が半年に一度あり、開発コミュニティへのフィードバックなどに使われます

• http://www.slideshare.net/openstack/openstack-user-survey-october-2013


https://wiki.openstack.org/wiki/How_To_Contribute

http://www.slideshare.net/openstack/openstack-user-survey-

OpenStack 開発体制

• プロジェクトごとの分業体制– プロジェクト内にもサブチームがいろいろ– プロジェクト間もかなり密にやりとりをしている

• Release Manager• Project 単位

– PTL (Project Technical Lead)• Release Cycle 毎に選挙で選ばれる• (通常は) Core Developer の一人

– Core Developers• プロジェクト毎に 10～20人程度• Patch Review で承認権がある (+2)

– Developers / Reviewers


OpenStack 開発体制

• Icehouse PTLs (Project Technical Lead)– Russell Bryant (Nova)– Mark Washenberger (Glance)– John Dickinson (Swift)– David Lyle (Horizon)– Dolph Mathews (Keystone)– Mark McClain (Neutron)– John Griffith (Cinder)– Julien Danjou (Ceilometer)– Steven Baker (Heat)– Michael Basnight (Trove)– Doug Hellmann (Oslo)


First Name が同じ人が多いです。・ストレージ関係は John・Mark は2人

開発サイクル• 半年に一回リリース

– 最新リリース : Havana (2013年10月)– 次期リリース : Icehouse (2014年4月)– その次 : “J”

• Design Summit Milestone release (数回) Release Candidates Release

• Feature Freeze Exception– Feature Freeze 以降に例外的に認められる

機能追加– 全体のProject Meeting での承認必要– コミュニティとして重要な機能に限定

• Milestone Release の一週間前には新機能のパッチはレビューに出しておかないといけないことになっている– レビュー期間確保のため

– レビューがたくさんある場合でも妥協せずにかなり先送り


機能追加の流れ

• Blueprint 作成 Spec 議論パッチ投稿レビュー Approve Merge

• 最近は

– Blueprint を作成した場合、Design や Spec のドキュメントを作成することになっている。

– ドキュメントなしにパッチを投稿すると、ドキュメントはないの？って聞かれる場合も多い。

– 昔はゆるかったけど・・

• パッチレビューが一番時間がかかる

– だいたいここで細かな議論が行われる場合が多い







こんなに変更を重ねるパッチはほとんどありません。

通常は数回レビューサイクルが回ると落ち着きます

Gating Job• 品質強化に向けて、Gating Test がかなり強化されて来ている。• Gating Test

– パッチが投稿されたとき、パッチの承認時に自動実行されるテスト– リリース前になると、パッチ承認からマージまで数時間かかることも。

• テストの種類– Tempest

• シナリオテストを主に実行• シナリオ 247個、テスト構成が 1～5個

– Grenade• バージョンアップのテスト環境

• インフラチームがすごいです。– IRC の #openstack-infra を見ていると、24 時間営業で誰かいます。



パッチが投稿されるごとに行されるテスト

Approve されたパッチテスト（順序通り検証される



Gating Job で実行されるシナリオテストの例7月の時点では36個→12月では247個

さらにこれがシステム構成毎に存在 (数種類Nova のみ、Nova + Neutronデータベースが MySQL, PostgreSQL など。

Jenkins がご機嫌斜めになるとき

• シナリオテストが失敗するパターン– 最近はこれが多い。– Neutron の Stability 不足が原因で失敗しているパターンが多く、みんなで頑張って解析しています。

• Jenkins の Gating Test が全滅するパターン– Python パッケージの依存関係が崩れる（Grizzly まではよくあった。現在は改善）• 複数のパッケージで要求しているバージョンがずれる• OpenStack 外のパッケージで Python3 でしか動かないバージョンが PyPI にアップロードされた

• Django のバージョンが上がって依存関係が・・・


開発に参加するには

• 参加のための手続きが必要（次ページ）– 主に、ライセンスの扱いに関する同意が必要

• パッチ投稿の流れ– Blueprint (機能実装)、バグ修正でも同じです。– パッチを投稿する前に、Blueprint かバグを必ず登録しましょう。• どんなに簡単なものでも！

• 1年以内にパッチがマージされた人をATC (Active Technical Contributor) と言います。– ボーナスとして OpenStack Summit の参加費 (400ドル?) が免除されます。


参加のための手続き• Launchpad にアカウントを作成する。 http://launchpad.net/

– バグ報告、Blueprint 登録に必要

• OpenStack Foundation に参加する– OpenStack Foundation の Individual Member になります。これで身分としてはコミュニティの

一員です。– 所属組織がある場合は入力しておきましょう。所属情報はここから取得されています。– https://www.openstack.org/join/

• Gerrit https://review.openstack.org/ に行き、Launchpad アカウントでログイン• Individual CLA (Contributer License Agreement) に署名する

– https://review.openstack.org/#/settings/agreements– メールアドレスと名前は Foundation に登録した情報と一致させておきましょう。この二つの情

報は公開されます。

• SSH 公開鍵を Gerrit の設定画面で登録しておきましょう。– パッチ投稿に必要です。

• 個人としての手続きは上記で完了です。

• 組織の一員として参加する場合– 組織単位で Contributor License Agreement (CCLA) に署名が必要。– CCLA には Contributor のメンバーリストがあり、そこに登録されていない場合は登録してもら

う必要がある。


http://launchpad.net/

https://www.openstack.org/join/

https://review.openstack.org/

https://review.openstack.org/#/settings/agreements

パッチ投稿の手順

• 詳細手順 : http://wiki.openstack.org/DevQuickstart– 日本語版 : http://wiki.openstack.org/DevQuickstart/ja (古い場合が多いです。参考！)


GitHub公開コード

手元のコード

GatingTest

Patch 1

Patch 2

Patch 3

Reviewers

SystemCheck

Approve

Comment

Auto Check

Merge

Develop/Modify

Propose

Clone/Pull

Release

人

Jenkins

Core Developers

http://wiki.openstack.org/DevQuickstart

http://wiki.openstack.org/DevQuickstart/ja

Core Developer は何をしているか？

• Patch Review– Milestone リリース前は忙しいです

• Bug Triage, Bug Fix– 登録されたものはだいたい誰かが見ています– バグ報告を見て、再現に取り組むことも多いです。

• Weekly IRC Meeting– Neutron の場合は 2100UTC @ Monday

• 日本だと朝 6 時– 開発状況の共有– 重要バグの確認– リリース前になると、Blueprint 実装状況の棚卸

• (Launchpad Answer)• (ask.openstack.org)• ドキュメント作成 (リリース前)


パッチレビューのときに見ていること

• 内容はもちろん大事です。– 何を実現したいのか？目的に沿っているか？一番大事– API は適切か？拡張性は？

• それ以外にもいろいろ見ています。– 機能追加、バグ修正部分に対応するテストコードがあるか– コーディングスタイル– ファイルの場所が適切か– REST API, RPC API のバージョン互換性確認– オプションパラメータの互換性– DB 変更がある場合は migration scripts があるか

• DB Migration : テーブル名、カラム名変更などでデータを引き継ぐなどの処理を行う。バージョンアップ時は必ず行いましょう。

• “nova db sync”, “neutron-db-manage” など


コミュニティに参加するにあたって

• 積極的に動きましょう。コミュニティは自律的に動く人の集合体です。

• みんな、基本的にはやさしいです。– 意見はぶつけあうので、その意味では議論になることもありますが、基本的には Welcome です。

• （ある程度は必要ですが）英語が得意でない人も、臆せず言うことはいいましょう。分からないことは聞きましょう。中身の方が大事です。

• IRC は ML よりも楽なこともあります。• パッチ投稿だけでなく、レビューもしましょう。

– レビューアは不足気味です。最初は大変ですが、OpenStack を理解する上でも必ず役立ちます。


最後に

• 開発体制などの話を説明して来ましたが、ユーザーの皆さんからのフィードバックが機能追加、品質向上を支えています。

• 小さなことでもよいので、バグ報告やメーリングリストでの質問を是非お願いします。

• 是非、開発にも参加を。

• 日本語で、という方は、日本OpenStackユーザ会のMLもどうぞ。


ありがとうございました


Technology

20131212 Okinawa OpenDays OpenStack