「OpenStack Summit May 2015 Vancouver」レポート #4（デザインサミットセッション）

5月18日よりカナダ・バンクーバーで開催中の「OpenStack Summit May 2015 Vancouver」。今回は、前回のレポートで簡単に触れた「デザインサミットセッション」について、その詳細を紹介したいと思います。

デザインサミットでは、今後半年間の開発サイクル（コードネーム：Liberty）での開発項目について議論し、アクションアイテムを決定していきます。

現在、OpenStackでは「Big Tent」（いくつかのコアとなるコンポーネントだけでなく、広く「OpenStackのプロジェクト」として認めていくことでエコシステムを大きくしていくという考え方）により、非常に多くのプロジェクトを抱えるようになっています。

そのため、すべてのデザインサミットセッションに参加することは難しく、今回筆者たちが参加できたものからトピックをレポートします。

デザインサミットの様子。「Etherpad」という共有メモツールを使用して議論を進めている

API Working Group

各OpenStackプロジェクトは、それぞれ独自のREST APIを持ちサービスを提供しています。しかし、各プロジェクトでREST APIはインターフェースとしてのデザインに一貫性がなく、ユーザが使いにくいという問題があります。

この問題を解決するため、OpenStack全体をまたいだREST APIの設計ガイドラインを作成するAPI-WG（Working Group）が立ち上がりました。

セッションでは、プロジェクトステートメントの確認・合意形成、API liaisons （各プロジェクトでのAPI担当者） の募集、MicroversionsをOpenStack全体方針への展開の議論などが行われました。

Work Sessionの様子。詳細なトピックの議論を行う。プロジェクタなどはなく、Etherpadを更新しながら議論していく

Nova

KiloリリースでのNovaの目玉機能として「Nova v2.1 API」がリリースされました。これはNovaの新しいREST APIであり、「強力な入力チェック機構」「APIバージョニング機構Microversions」という機能を持っています。

このAPIはリリースまで2年以上の開発期間を要し、多くの開発者が苦労して実装したため、セッションは「やっとリリースできたね。みんなおめでとう」という言葉とともに拍手で始まりました。

セッションでは、「複数Microversionsのテスト方法」「古いNova v2 APIの非推奨化プロセス」などについて議論されました。LibertyでもNova v2.1 APIを基に機能拡張が行われることになります。

Libertyでの重要なAPI機能拡張として、「Tasks API」の議論も行われました。現在、サーバ再起動・再構成といったAPIがありますが、各APIの実行状況を包括的にトラッキングするAPIがありませんでした。

例えば、サーバ再起動APIがサーバの状態変更を行う前に失敗した場合、サーバの状態はACTIVEのままであり、クライアントには再起動後のACTIVEなのかどうかを知ることが難しくなります。

この問題を解決するためにinstance-actions APIがありましたが、カバーできる状態が狭く、もっと包括的なAPIであるTasks APIが必要となりました。このAPIは1年以上前から議論されているものであり、Libertyで開発が進みそうです。

Neutron

Neutronのセッションでは「nova-networkとNeutronの統合」、「IronicとNeutronのIntegration」に関してそれぞれ複数のセッションスロットが割り当てられ、議論が大きく進みました。

・nova-networkとNeutronの統合

OpenStackにはnova-networkとNeutronという複数のネットワークスタックがあり、これらの統合は長年のテーマです。大きなポイントは「Open vSwitch（OVS）への移行を必須とするのか」という点です。

今回、大きな方向性としてはNeutronのLinux Bridgeドライバーの品質を十分に高めていくこと、nova-networkの「multi_host」というネットワークHA構成ではNeutron DVR（Distributed Virtual Router）の使用を推奨していくことが決まりました。

このほかにも、NovaとNeutronの違い（ローリングアップデート、テナントネットワークの自動作成、細かな機能の違いなど）を洗い出し、優先度付けが行われました。Libertyではかなりの進捗が期待できそうです。

・IronicとNeutronのIntegration

物理サーバをOpenStackクラウドに参加させた場合に、ネットワークの分離をどのように実現するかが大きなテーマです。

物理サーバを接続する場合には、物理スイッチのどのポートがどの仮想ネットワークに所属するかを知る必要があり、どのような接続形態があるのか、その情報をIronicとNeutron間でどのように渡すのかを議論しました。

また、Ironicは物理サーバをユーザに貸し出す際に一度「設定用ネットワーク」に接続して設定を行うため、ネットワークの付け替えを行う方法についても議論しました。大きな課題については方向性が見え、Libertyでは物理サーバのネットワーク分離が期待できます。

Magnum

現在、Magnumは「Kubernetes」 および「Docker Swarm」という二種類のコンテナ管理システムをバックエンドとして利用できます。それらのバックエンドとの連携時における TLSサポートや外部スケジューラのサポート、Magnum自体のスケールアウト方法などの基本機能の充実に注力することによって、東京サミットまでにプロダクションユースに耐える実装を行っていくことで合意しました。また、他のコンテナ管理システムのバックエンドにも対応していくため、プラグイン機構実装についても議論されましたが、結論は出ず今後の課題となりました。

その他にも、Cinder、Barbican、Neutronといった他プロジェクトと連携し、効率的に開発を行っていく方向性が感じられました。

QA

QA/Tempestは、すべてのコンポーネントのテストを実装・メンテナンスしようとしてきましたが、OpenStackコンポーネントがどんどん増える状況ではTempestが開発ボトルネックとなることが危惧されていました。そのため、セッションではQA/TempestはOpenStackのコアプロジェクト^［*］に注力することが決定しました。

それ以外のプロジェクトについては、個々のプロジェクトがテスト開発用のライブラリ「Tempest-lib」を使用し、個々の責任においてテスト開発を行っていくことになりました。

しかし、現在Tempest-libはまだ機能不足のため、Libertyリリースまでに個々のプロジェクトテストを統一的に実行できるようにするプラグイン機構の実装と、その実現に必要な各種ライブラリの実装を行っていき、十分利用可能な状態にしていくことが決定されました。

［*］現在QAチームが定義する「コアプロジェクト」には以下のものがあり、DefCore委員会（https://wiki.openstack.org/wiki/Governance/DefCoreCommittee）の定義にNeutronを加えたものです。

・Nova
・Glance
・Keystone
・Cinder
・Neutron
・Swift

QA／インフラ／リリースマネージメントミートアップの様子。最初にトピックを決定し、それぞれについて集合して議論・アクションアイテムを決定していく

インフラ

OpenStackコミュニティでは、主にLaunchpadをタスク管理のツールとして利用してきましたが、「イマイチ」ということで、インフラチームでは「StoryBoard」というツールを開発して利用を開始していました。

しかし、現状で機能が不足しており、今後もStoryBoardの開発を継続して使い物になるようにするのか、それとも他のOSSツールを利用するのか議論が行われました。しかし結論は出ず、東京サミットまでにはLaunchpad以外のツールに移行することが合意されました。

このように、「ないものは作ってしまえ」ということと、「本当に作る必要があるのか」を柔軟に考え、常に「最善・最適」を目指して活動しているのも「OSS的」と言えます。

デザインサミットの会場では、いつでもリフレッシュできるようにという配慮からか、常にスナック菓子やフルーツ、飲み物を飲食できる状態になっていた

いかがだったでしょうか。今回はあまり多くのセッション内容をお伝えできませんでしたが、それでもOpenStackのコアな技術について多くの熱い議論が交わされていたことが感じ取れたのではないかと思います。

次回はセッションから離れて、各企業の出展ブースの様子をレポートしたいと思います。お楽しみに！