はじめに

OpenStack Summit および Liberty Design Summit が 5月18日から22日の日程でカナダのバンクーバーで行われた。会場は、バンクーバー湾に面したコンベ ンションセンターで会場の窓から水上飛行機の離着陸をたびたび目にすることがあった。

Summit 全般

北米で開催されたこともあり、参加者は前回 (パリ) の4,700人を上回る6,000人であった。初日夕方のスポンサー展示ブースの開場と合わせて行われた Booth Crawl (各展示ブースで軽食や酒が振る舞われる) で、歩き回るのも困難な混雑ぶりが印象的であった。
形式面での今回の新たな試みとして、 Design Summit に Work Session というものが導入された。これは、20人程度が座れる長机のある部屋で行われるもので、少人数で実際の作業をしながら議論をしようというものである。

前回パリの Summit から導入された Superuser 賞は、前回はほぼ地元といえる CERN が受賞しており、今回は北米のケーブルテレビ会社 Comcast が受賞していた。次回東京ではどこになるのか期待したい。

Design Summit

Design Summit では主に開発者が今後の開発内容や方針について話し合う。詳しくは過去のイベントレポートを参照していただきたい。

 

Python 3

OpenStack を Python 3 対応させる話は、最近の Design Summit 恒例のセッションである。背景として、 Python 2 系列は 2.7 で終わりで新機能はもう追加 されないので、いつかは Python 3 に移行しないといけない等の事情がある。

セッションでは、 Oslo の Python 3 対応はできたので、少しずつ Python 3 に移行する、 Nova や Neutron 等のプログラム毎に Python 3 で動かすか選べるよう に Devstack を修正してテストを走らせる、といった方針が説明された。続いて、Python バージョンによって違うバージョンを選ばないといけない Library があ るがそれは新しいバージョンの PBR の機能を使えばいいことや、Ubuntu の Python 3.4 にはガーベジコレクタのバグが残っているなどの細かい話題が話されていた。

Python 3 対応は、以前は Eventlet が対応しておらず、 Python 3 のおすすめの方法である asyncio を使うようにしようかなどとメイリングリストで話さ れていたが、 Eventlet が Python 3 対応し大きな障害がなくなったことで最近スピードがあがっている印象がある。

サミット後の進展として、多くのプログラムで Python 3.4 の gate job が追加され、 unit test が実行されるようになっている。ただ、 Python3.4 の unit test は動くものだけ tox.ini に記載して実行する方式なので、 unit test でエラーが出ないからといってそのプログラムが Python 3 で動くわけではないことに注意が必要である。

なお、 Python 3 の対応状況は、Wiki ページで確認できる。

 

nova-net

これも最近の Design Summit 恒例の話題である。元々 Neutron (当時は Quantum という名前だった) は、将来的に nova-net を置きかえるものとして開発が始まったが、まだ nova-net からの公式の移行方法というものが存在せず、 nova-net も消せずに残っている。

Kilo では、 Design Summit で移行方法を議論して、いいところまで実装したところで、運用者からこんなものではだめだと突っこみが入ってご破算になった。今回はこの話題について 3つの枠を使って議論が行われた。

最初のセッションは “Cross Project workshops: Towards one Network Stack: Part 1 – Neutron Gaps and Concerns” という題で、 nova-net にあって Neutron に足りないものは何かが議論された。とはいえ、 nova-net で使っていて何も問題ないし新機能なんて要らないから Neutron でも同様に linuxbridge を使わせろという Jay Pipes 氏と、技術的に優れているから Open vSwitch がいいんだと主張する Kyle Mestery 氏のやりとりでほとんどの時間が消費され、あまり議論がかみ合っていない感じであった。他にもいくつか課題はあったものの、 Neutron の AMQP 負荷が高いという話を最後の 5分でちょっと話しただけで、 Etherpad に準備された議題はあまり話し合われることなくこのセッションは終了した。

2番目は “Get me a network” という題で、小さい部屋で行われたので参加していないが、nova-net と違って Neutron では (Network, Router 等を作成するために) たくさんの API を発行する手順を踏まないと VM がネットワークを使えなくて面倒なのをどうにかしたいという問題が話し合われた。
この問題についての関心は高く、翌日にはもう担当が決まって spec が Gerrit にあげられていた。

3番目は “Nova: Towards one Network Stack: Part 2 – Path forward in Liberty” という題で、作業の優先順位などを議論していた。
DVR を linuxbridge でも使えるようにするという話も出ていた。これは、nova-net にある冗長化機能に相当するものを Neutron では DVR で実現するという方針であったので、 nova-net から Neutron + linuxbridge への移行をサポートするのであれば、当然 DVR も使えるべきであるという理由による。

サミット後の進展としては、 linuxbridge の gate job が追加されてテストがちゃんと行なわれるようになり、発見されたいくつかのバグが修正された。
“Get me a network” に関しては、当初は network, subnet 等を自動割り当てするコードを書く方針であったようだが、承認された spec では、新規コード追加で対応するより運用で対応するという風にまとめられている。具体的には、クラウド運用者が shared private network をどう設定すればよいかをドキュメントに書くということになった。また、DVR を linuxbridge に対応させる話は結局のところ進展がなかったようである。
次の東京サミットでも nova-net の話題は続くと思われる。

 

neutron

Neutron のセッションは水曜と木曜に 20弱のセッションが行われ、金曜の午前にも Contributor Meetup が行われた。その中から興味を引いたものをいくつ か紹介する。

  • VLAN aware VMs
    Cisco の Ian Wells 氏による提案である。現状では、複数の Neutron network を VM に接続したい場合は Network の数だけ VIF (Virtual Network Interface) を作成する必要があるが、Neutron 側でそれらを VLAN でまとめて 1つの trunk port として VM に見せようというものである。単に Compute Node のホスト側の通信をそのまま VM に渡すのではなく、見せていい Network のパケットのみを、 VLAN タグの付けかえなどを行ったうえで見せるものである。この機能の使用例としては、アプライアンス等のレガシーな VLAN 対応アプリケーションを動作させるといっｓたものがあると説明された。

    サミット後に spec は承認されたが、現時点 (8/14) で開発はされていないようである。

 

  • Ironic 
    冒頭で Ironic がどうネットワークを使うかが簡単に説明され、テナント分離をどう実現するかについて議論が行われた。現状の Ironic ではデプロイ用とサービス用のネットワークが同じであり、しかもテナント分離ができていない。

    テナント分離を実現するには、ベアメタルサーバがどのスイッチのどのポートに接続されているか、スイッチはどうやってプログラミングすればいいのか等が課題となる。

    セッションでは、スイッチの接続ポート情報は LLDP で取得すればよいとか、ベアメタルサーバが複数の ToR スイッチに接続されてたらどうすればよいのか等が議論された。

    サミット後に、Neutron と Ironic の興味をもった開発者が合同で IRC ミーティングを行い、 Ironic 側では ironic-ml2-integration, network-provider と いう 2つのスペックにまとめられた。情報は Ironic の DB に持たせておいて、port binding で Neutron に情報を渡してスイッチの設定をしてもらう、というふうになっている。

    Gerrit トピックで検索すると状況がわかるが、現時点 (8/14) では実装はまだ道半ばといった感じである。

 

  • QoS
    帯域制御の話題である。 QoS はベンダードライバーにはいくつか実装があるのだが、共通 API がないことが問題として認識されている。この話は以前のデザインサミットでもあったが、その時は提案のうけがあまりよくなかった上に、実際に作業をする人が現れなかったのでそのままとなった。

    今回のサミットでは、APIは Admin だけが叩けるものなのか、 DSCP remarking をつかうなら制限をかける必要があるよなどといろいろな議論が行われ、サミット後に議論して Feature ブランチで作業することとなった。

    トラフィック毎に QoS を指定できるようにするべきではないか等の意見もでていたが、現時点 (8/14) では、最も基本的な帯域制御に機能を絞ったものが Feature ブランチでほぼできあがっている。今後 Libetry リリースに間にあうようにマスターにマージされるはずである。

まとめ

サミット後の進展として、 OpenStack 全体のリリースモデルの変更 (プログラム毎にリリース周期を変えられる、バージョン番号の付け方)や、人手が不足しているので Stable Branch のリリースをやめることになった。
Neutron では、 lieutenant システムが導入されて Core Reviewer が分野毎に新たに追加されたことや、従来の Blueprint の スペックレビューに代わる RFE システムが導入された。

8月末には Liberty-3 タグが切られ、その時点で開発は基本的に Feature Freeze となり、バグ等を修正し 10月中旬に Liberty がリリースされ、10月末に東京でのサミットが開催されることになっている。