OpenStackの品質を保つ仕組みとは？：QA/Infraプロジェクトの最新動向

OpenStack開発コミュニティには、投稿されたパッチを自動的にテストし、そのパッチが悪影響を与えていないことを確認する仕組み「ゲートテスト」があります。QAプロジェクトとInfraプロジェクトが連携してこのゲートテストを実装、実行しています。

QA（Quality Assurance＝品質保証）プロジェクトには

• Tempest: 統合テストを実装する
• Grenade: アップグレードテスト（古い設定ファイルが使えるか、などをテスト）を実装する
• Devstack: 開発、テスト用OpenStackクラウドをデプロイする

のコンポーネントがあり、ゲートテストではDevstackでデプロイしたクラウド環境に対して、TempestとGrenadeを実行することで投稿されたパッチの妥当性をテストすることにより、品質を確保しています。

またInfraプロジェクトでは、投稿されたパッチによってどのような環境のクラウド環境をデプロイし、どのTempestのテストを実施するのかなどが細かく管理されています。例えば、Ironic（ベアメタル）パッチが投稿された場合はDevstackでIronicを使ったクラウド環境をデプロイし、Ironicに関連したTempestテストが実行されるように管理されています。それ以外にもパッチを投稿する際に利用するgerritなどもInfraプロジェクトが管理しています。

本記事では、QA/Infra関連デザインセッションから、以下の3つのトピックをとりあげます。

1. 複数ノード環境でのテスト実施
2. API Microversionsテスト
3. プロジェクトテスト状況の可視化

それぞれどのような議論が行われたのか、解説していきます。

1. 複数ノード環境でのテスト実施

長い間、ゲートテストは単一ノードによる「オールインワン」構成のOpenStackクラウド環境を使ってテストをしてきました。しかし、実際の商用環境では、複数ノードでOpenStackクラウド環境を構成するのが一般的であり、開発コミュニティでのテスト環境と商用環境に大きな差異がありました。その結果、複数ノード環境で顕在化する障害（ライブマイグレーション機能のバグ等）をコミュニティで検知、再現させることが難しいという課題がありました。

この課題を解消するため、開発コミュニティのインフラチームとQAチームが協力し、複数ノード構成環境を使ってゲートテストを行う枠組みができてきました。

今回のデザインサミットでは、どのような構成で複数ノードのゲートテストを行っていくのかが議論されました。OpenStackの魅力として、クラウド運用者が自由にクラウド環境の構成物を選択できることがあります。例えば、ネットワークとしてnova-networkを使うかNeutronを使うか、仮想化としてqemu/kvmもしくはXenかなど。

デザインサミットでの結論として、

• Neutron構成（DVR機能を無効化）
• Neutron構成（DVR機能を有効化）
• nova-network構成（multihost機能を有効化）

でのゲートテスト実施を目指していくことになりました。これは、ネットワーク構成が開発コミュニティにとって直近の課題であり注力すべきという共通認識を反映したものです。

今後、さらに商用環境を念頭にしたOpenStack全般の品質向上が期待できます。

2. API Microversionsテスト

バージョンKiloにおいて、NovaとIronicに「microversions」というAPI機能が実装されました。これはAPI変更を細かくバージョニングし、どのバージョンがサーバ側で動作するのかをクライアント側で指定できる仕組みになっています。他のプロジェクトもmicroversionsを実装する計画を持っており、OpenStackの標準的機能となってきています。

しかし、ゲートテストを実施するTempestではmicroversionsに対するテストが行われておらず、早急にテスト実装を行う必要がありました。今回のサミットではNova、Ironic、Tempestプロジェクトの開発者が集まり、テスト実装方式が議論されました。結論としてmicroversionsを実装する他プロジェクトへの展開も念頭に、現在提案されているIronic向けmicroversionsテストパッチから共通処理を抽出しテスト共通基盤として実装した上で、Nova、Ironic個別のテストを実装していくことが決まりました。これにより、microversionsを実装するすべてのコンポーネントで共通的なテストが実行されるようになります。

3. プロジェクトテスト状況の可視化

OpenStackコミュニティでは、すべてのパッチに対して必ずテストが行われますが、その結果は個々のパッチやジョブ単位でしか把握できず、プロジェクト全体やOpenStack開発全体としての傾向が把握しづらい状況でした。この状況を改善するため、Subunit2SQL^※1とHealth Dashboard^※2という2つのプロジェクトにて開発が行われています。

Subunit2SQLは、Tempestのテスト結果（Subunit形式）をデータベースに格納し、そのDBアクセスを行うPython APIの提供をしています。Health Dashboardは、Subunit2SQLのAPIを利用し、REST APIおよびWeb UIを提供しています^※3。いずれもまだまだ荒削りであり、その表示内容、性能について、これから改良を行っていくことが話し合われました。プロジェクトの品質状況、テスト安定性を把握するために非常に便利なコンポーネントになっていくと考えています。

※1: http://git.openstack.org/cgit/openstack-infra/subunit2sql

※2: http://git.openstack.org/cgit/openstack/openstack-health/

※3: http://status.openstack.org/openstack-health/

OpenStack Health Dashboard

「Mitaka priorities」という最終日のセッションでは、タスク明確化、優先順位付け、担当者、ターゲット決定を実施しました。ここまでであれば、「普通のソフトウェア開発」では当たり前の事です。しかし、その優先順位０番目に「FUN」が置かれました。OpenStack（を含むOSS）開発コミュニティでは、「楽しさ」を重要視することにより、開発者のモチベーションを維持し、結果的に開発効率の最大化に繋がると考えていることがわかる象徴的な出来事と感じました。

 

QAデザインセッションの様子