20130724 openstack-3rd-anniversary-amotoki

OpenStackの開発体制と品質維持への取り組み～ Core Developer から見た stable release の現状

Akihiro Motoki (@ritchey98)Jul 24th, 2013

2013/7/24 OpenStack 3周年記念イベント 1

自己紹介

• 元木顕弘 @ritchey98

• OpenStack Developer– Neutron (Quantum) Core– Horizon Core

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


OpenStack Projects & Program• Programs

– OpenStack Programs are efforts which are essential to the completion of our mission.

– https://wiki.openstack.org/wiki/Programs– Project だけでなく OpenStack を支える様々な活動も含む枠組み。

• Integrated Projects– Nova, Swift, Glance, Keystone, Horizon, Neutron, Cinder– Ceilometer, Heat

• Incubated Projects– Trove (Database as a Service), Baremetal (Ironic)

• Support Programs– Oslo (Common Libraries), Infrastructure, Documentation– Quality Assurance (Tempest, Grenade)– Deployment (TripleO)


https://wiki.openstack.org/wiki/Programs

OpenStack 開発体制

• Release Manager: Thierry Carrez (ttx)• Project 単位

– PTL (Project Technical Lead)• Release Cycle 毎に選挙で選ばれる

• Core Developer の一人

– Core Developers• プロジェクト毎に 10～20人程度

• Patch Review で承認権がある

– Developers / Reviewers


OpenStack 開発体制

• Havana PTLs (Project Technical Lead)– Russell Bryant (Nova)– Mark Washenberger (Glance)– John Dickinson (Swift)– Gabriel Hurley (Horizon)– Dolph Mathews (Keystone)– Mark McClain (Neutron) markmcclain– John Griffith (Cinder)– Julien Danjou (Ceilometer)– Steven Hardy (Heat)– Mark McLoughlin (Oslo) markmc


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

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

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

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

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

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

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

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


機能追加の流れ

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

• Neutron の場合には

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

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

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

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

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





Core Developer は何をしているか？

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

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

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

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

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


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

• 内容はもちろんですが、

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

– DB Migration : テーブル名、カラム名変更などでデータを引き継ぐなどの処理を行う

– “nova db sync”, “neutron-db-manage” など– バージョンアップ時は必ず行いましょう


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

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

• テストの種類– Tempest

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

– Grenade• バージョンアップのテスト環境• まだ実験段階

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



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

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



Gating Job で実行されるシナリオテストの例今日の時点では36個あった。

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

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

• たいてい Jenkins の Gating Test が全滅する

• Python パッケージの依存関係が崩れる– 複数のパッケージで要求しているバージョンがずれる

– OpenStack 外のパッケージで Python3 でしか動かないバージョンが PyPI にアップロードされた

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

• 特定のパッチが影響する場合– パッチの Revert での対処が中心

– 確率的に起こるエラーで解析が難航する場合は、一時的にテスト結果が「参考扱い」 (non-voting) になる• 最近だと、Neutron の L3-agent RPC 周りのエラーが難航


OpenStack のリリース

• 直近 2 リリースがサポート対象– 今だと Grizzly (2013.1) と Folsom (2012.2)– 一番新しいリリース : 通常の Bug Fix と Security Fix– 一つ前のリリース : Security Fix のみ

– これ以外に Distributer によるサポートが別途ある

• リリース後も定期的に “Stable Release” が行われる– Bug Fix を集めて、定期的にリリース。

– Grizzly だと 2013.1.1, 2013.1.2 といったバージョン番号

– 間隔はおおよそ 1.5～2ヶ月。• 明確には決まっていない。Folsom はこれまで 4回


Stable Release の運用体制

• Stable Management Team– Stable branch へのパッチの承認権を持つ– Core Project PTLs– プロジェクトの stable branch 担当 (Core member)

• 各プロジェクトの Core Member– Stable branch へのパッチのレビュー (+1)

• Security Vulnerability Team– Security 系のバグ報告への対応– OSSN (OpenStack Security Notes)


Stable Branch の運用の流れ

• バグ報告– Stable release に影響するバグの場合は

“grizzly-backport-potential” タグが付与される– このタグは誰でも付けることが可能。

実際には Core メンバーが付けることが多い

• Development branch (master) でのバグ修正– 各プロジェクトの Core Member による承認でマージ

• Stable Branch への backport– 原則として master branch で修正を行なってから backport する– ここで修正が発生した場合は master branch を修正してから、それを取り込む– Stable Maintenance Team による承認でマージ– デグレがないことが明らかに確認できるパッチであることが求められる。

• Stable Point Release– リリース予定の約一週間前から Freeze 期間に入る– Stable-maint ML にテストの呼びかけが流れることが多い

• Stable Point Release– ML でアナウンスが流れる


リリース間での互換性• ある機能が廃止される場合は、いきなり削除されることはない。

– Deprecated (非推奨) 扱いのリリースをはさみ、その次のリリースで削除することになっている。

– Depreacated 扱いになったら、次のリリースが出るまでには移行しましょう。

• DB のスキーマ変更は Migration Script で対応。– 以前のリリースでのデータを新しいテーブルに引き継ぐなど– アップグレード時は migration script を実行して下さい。

• 設定ファイル– 可能な限り、前のリリースの設定ファイルでそのまま動くように配慮している– 名前などが変更された場合、前の名前のオプションは deprecated マークが

付けられ、これを使っている場合はログに出力される。

• コマンド– コマンド名、サブコマンド名が変更される場合もいきなりなくなることはありま

せん。– Havana Release では Quantum -> Neutron の名前変更に伴い、

“neutron” コマンドができますが、”quantum” でも使えます。– glance のサブコマンド名の再編があった時も、前のサブコマンドも使えるよう

に配慮されました。


リリースにまつわる XXX• リリース直後は安定しない？次の stable point release (.1) を待った方がいい？– 待った方がいいかも。– リリース直後にバグレポートがかなりたくさん来て、Bug

Fix もかなり盛んに行わる傾向にある。– リリース前はやはりかなりバタバタしている印象

• 新しいリリースを使った方がいいか？– 新しく構築し始めるのであれば、使った方がいいでしょう。

– 以前に比べると、安定性・互換性の配慮はかなり向上されているので、同じ機能を使う分には安定度が上がると思います。

– 新機能が必要な場合は当然ですね


リリースアップグレード• リリース間でのアップグレード

– 個々のプロジェクトでは、内部APIも含めて、リリース間での互換性は注意が払われている

– システム全体としては、まだまだ検証が不足しており、事例の集積が必要な状況• ドキュメントでもほとんど記載がない

– 本番環境でのアップグレード事例は OpenStack Summit などでいくつか報告されている• Rackspace は開発版を Monthly にアップグレードしている

• nova-network Neutron への移行– 将来的には nova-network は廃止して Neutron に一本化する方向で

は、ほぼ合意されている。時期は全く未定。– Havana Summit で移行方法、サービス継続性などに関してセッション

が持たれた。– Havana では、nova-network → Neutron の移行に必要な項目を洗い

出して試していくことになっているが、あまり進んでいない。– ということで、しばらくは nova-network は存在し続けることでしょう。


最後に

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

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

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


ありがとうございました


Documents

20130724 openstack-3rd-anniversary-amotoki