はじめに

OpenStack Summit および Juno Design Summit が 5月12日から16日の日程で米国ジョージア州アトランタで開催された。

アトランタはアパラチア山脈の裾野に位置し、交通 (鉄道) の要衝として発展した都市である。桃が名産品らしいが農業にはあまり適してないらしく、空から見ても農地のようなものは見られなかった。公民権運動で有名な Martin Luther King, Jr. はアトランタの出身である。

また、『風と共に去りぬ』は当地を題材としている。

Summit 全般

前回までは4日間の日程で行われていたが、今回は5日間にわたって開催された。
前回までのスケジュールでは、一般向けセッションと Design Summit が完全に重なっているため、一般向けセッションに開発者がいないという問題があった。アトランタでは、この問題を低減するために Design Summit を1日後ろにずらして初日には行わないという日程となっていた。

また、Ops Meetup という新カテゴリーが作られた。Ops Meetup のセッションでは、運用者がどう運用しているかを語り、時として開発者に文句をいっていた。

他のニュースサイト等で既に報じられているので詳細は省くが、今回の新しい話題を特徴づけるキーワードとして、Marketeplaceと Superuserが挙げられる。

Design Summit

全般

今回の変更点として、Pod Area という丸机が並んでいてプロジェクト毎に非公式の会議ができる部屋が設けられた。また、初日には Cross-project workshop トラックが設けられ、OpenStack 共通の課題 (プロジェクト間の API 整合性 (consistency) など) について議論が行われた。

なお、Design Summit がどういうものかについては過去の記事を参照して頂きたい。

 

Neutron

Neutron の Design Summit は全部で 2日半の日程で行われた。最初のセッションでは Juno に向けての重点項目などが話された。そこで挙げられた項目は、nova-parity (nova-network にはあるが neutron にはない機能を補完するもの)、テスト強化、core refactoring、新しい blueprint 承認プロセスなどであった。

以下に興味をひいたいくつかのセッションについて述べる。

  • nova-parity
    parity は同等性という意味で、Neutron プロジェクトでは、不足している点を実装して nova-parity を実現しようとしている。

    Juno リリースで nova-parity が実現できない場合、Neutron が インキュベーションプロジェクトに落とされるのではないかという話もあり、これは優先度の高い課題である。6月には nova-parity の実現のために有志が米国ミネソタ州に集まって3日間の会議が開催されたほどである。

    デザインサミットでは nova-parity 関連のセッションがいくつかあったが、以下ではマイグレーションと DVR の 2つの話題について述べる。

    1 つめの話題は nova-network から neutron へのマイグレーションである。
    これは、ネットワークの瞬断は許容して、VM を動かしたまま neutron 環境に移行できるようにするものである。会場からは、マイグレーションに失敗したときのためにロールバック機能が必要であるという意見が出ていた。

    2 つめの話題の DVR は Distributed Virtual Router の略である。現状の L3 Agent によるルーティングは単一障害点であり、これをどうにかすることが nova-parity の観点からも求められている。DVR では、データセンター内の通信 (East-Westトラフィック) は各 compute node で動作する L3 Agent に分散され、性能上の利点も期待される。ただし、North-South トラフィックのうち SNAT を利用するものは service node 上の L3 Agent を経由するという若干複雑なつくりとなっている。DVR はやっていることが難しいという点もあるのか、セッションではコードを書いた HP の方が淡々と説明しているという印象であった。

    なお、上で触れなかった点を含め Neutron に不足している点は以下の Wiki に網羅されている。
    https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage

 

  • LBaaS
    LBaaS は loadbalancer as a service の略称である。neutron の LBaaS は L7 ロードバランシングや SSL サポートの機能が不足しており、いくつかの会社は自前の LBaaS プロジェクトを持っているようである。hp は最近これらの機能をコミュニティに還元したくなったようで、サミットのしばらく前から LBaaS での活動を行っていた。一方、neutron プロジェクト全体としては LBaaS の優先度はそれほど高くなく、特に Icehouse リリースでは他の問題が大きかったために LBaaS にはほとんど進展がみられなかった。

    サミットでは、Pod エリアに50人ほど集まって LBaaS を neutron から別プロジェクトとして分離するかについて 2時間ほどの大論戦となった。その場では、別プロジェクトにすると gate system の設定などの作業が必要になって開発はかえって遅くなるなどの分離のデメリットが繰り返し語られて、それでも分離するのであればリリース毎に進捗を評価して決めればよいのではないかと言われて、分離を提案していた hp の Susanne はしぶしぶ納得していたようであった。だが、サミット後の様子をみると、分離後の受け皿として Octavia プロジェクトというものができていたりする。

    一方、サミットの公式プログラムでは、LBaaSのメインの開発者である Eugene が新しい DB オブジェクトモデルや API の話を淡々としていて、Pod エリアでの非公式な議論との温度差が印象的であった。

 

  • advanced services
    advanced services というのは FWaaS, VPNaaS, LBaaS などの総称である。
    これらの複数の advanced services をどうやって組みあわせて使用できるようにするかという話題は service chaining と呼ばれ、Icehouse デザインサミットでも議題になっていたが、コード上の進展はみられていない。

    今回の主な話題は flavor framework と service chaining であった。flavor というのは nova における flavor を意識して名付けられたものであるが、意味は異なる。neutron での flavor では、クラウド管理者があらかじめ flavor をいくつか定義しておき、エンドユーザーが例えば LBaaS を起動するときに具体的な LBaaS ドライバ名ではなく flavor を指定させるようにすることで、エンドユーザーから advanced services のドライバ名を隠蔽することができる。サミットとその前日の Pod area では、flavor と実際のドライバをどう対応させるかについて長時間議論がなされていた。
    この議論は現時点 (7月中旬) でもまだ継続中であり、Juno に入るか微妙なところである。

    service chaining の代案として、私も virtual resoure for service chaining という題で少しサミットで話した。
    参照: https://wiki.openstack.org/wiki/Neutron/VirtualResourceForServiceChaining

    関連するキーワードとして NFV (network function virtualization), ServiceVM がある。これらと関連してこの分野がどう進展していくか興味がもたれる。

 

他のプログラム

Neutron 以外の話題として、AMQP 1.0 ドライバについて述べる。

  • AMQP 1.0 ドライバ
    AMQP は OpenStack の内部通信に使われているプロトコルである。

    AMQP 1.0 は 2012 年に決まった仕様で、それ以前のバージョンとは互換性がない。現在 OpenStack の AMQP ドライバは rabbitmq 用と qpid 用に分かれていて、それぞれバージョン 0-9-1, 0-10 を使用している。

    発表では、AMQP 1.0 の利点として、性能向上していること、実装に依存しないこと (ただし現在の rabbitmq では未実装の機能を使っている)、peer-to-peer プロトコルであるなどの利点が述べられていた。
    ただ、Proton ライブラリというものが必要で、パッケージングをどうしようなどといったことが話されていた。

    以下に性能評価結果がある。ちょっとびっくりするくらいの性能向上がみられる。
    参照: http://people.apache.org/~gsim/oslo.messaging_scalability.pdf

最後に

Juno は 10 月 16 日リリース予定であり、次回のサミットは今回と同様の日程で 11月 3-7 日の 5 日間にわたってパリで開催される。