The OpenStack Summit November 2013 in Hong Kong 開発者セッションレポート

11月5日から8日にかけて香港で行われた OpenStack Summit に参加した。香港は北緯22度と結構南にあり、天気予報では最高気温は30度近かったので東京の9月ごろの蒸し暑さを想像して行ったところ、ちょうど温暖で快適な気候であった。

会場は Asia World Expoという、東京ビックサイトや幕張メッセほどの規模のある巨大会場の一部を使って行われた。私が2012年10月に参加した、San Diego でのOpenStack Summit は、ホテルの会議設備で行われていたことからも、規模が急拡大したことが分かる。

私が主に参加したのは、開発者向けの Design Summit で、一般向けセッションなどの他の会場とは隔離されたフロアで行われていた。
セッション数が最も多かったのが Nova で、その次が Neutron なのは相変わらずであった。

Design Summit はそれほど急拡大した印象はないが、会議は6並列で行われ、Marconi や Trove など開発中のプロジェクトを含めると 20 程度のトピックがあり、着実に規模は大きくなっている。

開発者のセッションでは、まず議題となる機能について簡単なプレゼンが行われ、その後の大半の時間でその機能についての議論が行われるというのが基本 的な進行である。新機能は、launchpad.net の blueprint というもので管理されており、普段オンラインで blueprint について議論しているものを実際に会って議論するのが Design Summit であると言うこともできる。従って、プレゼンは最低限のもので、事前に blueprint を読むなどして予習していかないと議論についていけないことも多い。

議論では Etherpad が用いられる。今回の etherpad のリンクのまとめはこちら。

ネットワーク管理コンポーネント Neutron のセッションに主に出席したが、他のプロジェクトの様子として、新たなプロジェクトである Heat と Ironic と TripleO についても、プロジェクトの概要も含め簡単に紹介したい。

TripleO とは、O が3つということで、OpenStack-on-OpenStack の略である。
OpenStack の上に OpenStack を構築するもので、それぞれ Undercloud、Overcloud と呼ばれる。単に検証用に実マシン台数を削減するために Nested Virtualization をしようという話ではなく、Undercloud で Ironic を使うことで Nested Virtualization の性能オーバヘッドはなくなり、実運用に使用するシステムが構築できる。Ironic についてはこちらの項目も参照されたい。

まだ開発途上のプロジェクトであるが、セッションの参加者は多く活発な議論が行われていた。このセッションでは TripleO での標準的な HA 構成をどういうものにするかを議論していた。そのために、AMQP や DB など、どの Overcloud Service を多重化しないといけないかを話し合い、その場で Etherpad に列挙していった。

Glance のバックエンドに何をつかうかでもめていたが、多数決で Ceph に決まったようだ。標準実装としてまず Ceph を使いましょうというだけで、後に Swift を使ったものなども実装されるかもしれない。

Neutron のセッションは、Havana リリースの総括と、次期バージョンの Icehouse に向けての方針を発表する、このセッションから始まった。
Icehouse の方針として、ドライバとプラグインを Compatible と Unknown に分類すると述べられた。これは、ベンダーによって書かれたコードが動くものかどうかよくわからなくなるのを嫌ってのことだと思われる。Icehouse がリリースされて “J” のリリースサイクルが始まったら unknown なコードは消すかもしれないとのことであった。

Compatible と分類される条件として、”regular active participant” をバグの連絡先として登録することや、smokestack test を icehouse-2 までに書くことなどが挙げられていた。

セッションの枠は1つであるが、中身は20分ずつ2つに分かれている。
Neutron は話題が多く、このような形式のセッションがいくつもあった。

このセッションの前半では、ベンダー非依存の QoS API を作る話について議論された。対応する blueprint はこちら。

提案する API や CLI 例が示されたが、OVS でポート単位で DSCP (Differentiated services Code Point) を割り当てるというものだったので、受けは良くなかった。
会場からの意見としては、プロトコル等によってトラフィッククラスを分けるのはどうやって表現するのかとか、API を Nova の flavor (VMのメモリ等のサイズを指定するもの) のように抽象化したほうがいいのではないか、というものがあった。時間内で議論はまとまらず、API の議論はメイリングリストで続けてはどうかと言われていた。

後半では、ML2 プラグインが作られたことで、LinuxBridge と Open vSwitch プラグインは時代遅れとなったが、これらが運用されている環境でどう ML2 に移行させるかという話題であった。Agent の設定をどうするか等の議論もされた。また、発表者は DB のマイグレーションをやりたくないらしく、会場に誰かやらないかと聞いて、みんな顔を見あわせ沈黙するというありがちなひとコマも見られた。

Ironic は、昔は Nova の仮想化ドライバの1つで、Baremetal と呼ばれていたが、Nova から別プロジェクトとして切りだされた。
当初は特殊な用途の性能チューニングのためのものと思っていたが、この仕組みを使うことで OpenStack API を使って物理マシンの管理ができる。結果として Ironic になってこの方向に大きく進化している。TripleO と組み合わせることで、今後のクラウド管理の標準となっていく可能性を秘めたプロジェクトである。

OpenStack API で物理マシンの管理をするのは若干無理があるとも言えるが、OpenStack API 一つで済んでしまうという利点も大きく、今後必要な機能が順調に開発されていくかがポイントとなろう。

参加したセッションでは、Local Storage を OpenStack の枠組みで利用するにはどうしたらいいかが議論されていた。ボリューム管理の Cinder を使おうというのが大勢であったが、それではうまくいかないという人もいて議論となっていた。Ironic ではセキュリティの問題もあって、インスタンスが終了したら Local Storage はきれいにクリアしないといけなかったはずだが、折り合いをどうつけるのかが疑問である。

余談であるが、セッションには “ironically we can manage coffee too” と書いてある服をきている人達がいた。Ironic の知名度をあげるためか、遊びなのかは分からないが、開発者仲間で示し合わせて作って着てきたのであろう。

Ironic に関しては、物理マシンの状態 (温度計など) を監視する必要もあり、Ceilometer を利用して行う方針のようで、出席はしなかったがそのためのセッションもあった。動向については、以下の blueprint が参考となる。
https://blueprints.launchpad.net/ironic/+spec/add-ceilometer-agent
https://blueprints.launchpad.net/ceilometer/+spec/monitoring-physical-devices

Heat は、OpenStack オーケストレーションを行うモジュールで、AWS では CloudFormation が相当する。テキストファイルの記述に従って VM の起動やネットワークの設定を行い、VM内のアプリケーションのインストールや設定ファイルの配置なども行う。

オーケストレーションを指示するテキストファイルは元々は AWS CloudFormation と同じ文法のものでやっていたが、独自の HOT (Heat Orchestration Template) 形式のものも使われるようになった。
この Heat 最初のセッションでは、HOT 形式をどう拡張していくかが議論された。会場から挙がる、こんなことやりたいという声が Etherpad に列挙されていった。項目数が多いので少しづつ実現していくようである。一例として、auto-scaling で VM が増えたら既存の VM の設定も更新する機能が必要だという意見が聞かれた。

具体的には、セッションの Etherpad や、以下の Wiki が参考になる。
https://wiki.openstack.org/wiki/Heat/Software-Configuration-Provider