はじめに

OpenStack Summit および Ocata Design Summit が、10 月 24 日～28 日の日程でスペインのバルセロナで行われた。初日の 24 日はスポンサーブースのみの開場で (私は日程の都合で参加しなかった)、一般セッションは 25 日からの 3 日間、デザインサミットは 25 日からの 4 日間の日程で行われた。

バルセロナの緯度は日本の津軽海峡あたりに相当するが、体感では東京より暖かく、地中海性気候のため 10 月は雨がちな季節だそうだが、滞在期間中はほとんど降られることはなかった。

キーノート等

初日のキーノートでは、Certified OpenStack Admin (COA) という資格が紹介された。OpenStack Foundation または Training パートナー経由で受験できるもののようで、会場でも COA の受験料割引などのプロモーションをいくつか見かけた。また、OpenStack ユーザの 8 割は非技術系の企業であって、一般企業への利用が拡大していることや、ユーザやクラウドの規模の統計が示されていた。デモでは、Kolla, NFV doctor, Vitrage などが紹介された。NFV doctor のデモでは司会者が刃渡り 30cm はありそうな巨大な鋏を持ちだしてイーサネットケーブルを切断し、回線のフォールバックが正常に行われることを聴衆に示していた。

 

事例紹介では、開催地近郊のユーザ事例をメインに扱うのが恒例だが、スペインの事例として Banco Santander が、ヨーロッパの事例としてイギリスの衛星テレビ局 Sky やドイツテレコムが紹介されていた。科学プロジェクトでの利用例としては、おなじみの CERN の他に、SKA プロジェクトが紹介されていた。
SKA プロジェクトにはいくつかのゴールがあるようだが、紹介されていたのは重力波の観測で、これはパルサーからの電波を観測してその到達時刻が重力波でずれることを利用して行うものである。大量のアンテナからの広帯域の信号を処理する必要があり、このために 0.5 exaflop/s の計算能力が必要で、予算等の制約から 20MW/exaflop/s の電力効率を実現しなければならない等の課題が示されていた。CERN の発表でも予算の制約が厳しい (従って OpenStack で運用コストを下げないといけない)といったことが言われていた。

2 日目のキーノートでは、Infra プロジェクトが紹介されていた。Infra プロジェクトは、CI システム review.openstack.org 等を管理するもので、世界中に散らばった多数のクラウドを使ってサービスされているとのこと。デモでは壇上からヨーロッパの拠点を追加するパッチ (http://review.openstack.org/#/c/390728) を投稿し、客席の core reviewer 2人が +2+A して CI job が動作したあとパッチがマージされ、実際に拠点が追加されるといった、実際に OpenStack のパッチを投げたことがある人でないと意味がよくわからないデモを行い、一部にウケていた。

 

次のデモでは、20人ほど並んで座れる長机が搬入され、その上に並べられたノート PC を使ってそれぞれの会社の OpenStack クラウドを操作し、Docker Swarm や LAMP stack を起動するという共通課題を行って相互運用性をアピールしていた。この件では IBM が RefStack を通じて貢献したと宣伝されていた。

他に Platform9 が Horizon から OpenStack と AWS を統一的に操作できるようにしたことや、Intel の Diversity サポート活動の一環としてメキシコで Hackathon を行ったこと、Kolla, Magnum, Kuryr 等の各プロジェクトの簡単な説明とそれらを使ったコンテナのデモが行われた。

Design Summit

Design Summit および Ops Summit は会場の端で行われていた。このような一見行き止まりの壁のような所を通り抜けていく必要がある。一般人が開発者の場所に迷い込まないための対策であると思われる (以前は区別が明確ではなく、一般セッションと間違えて大量の聴衆が押し寄せるといったことがあった)。

 

Ops: Neutron Pain points

Neutron を運用する上での困ったことについて話し合うセッション。Neutron では security groups の実装に conntrack を使っているのだが、接続数の上限にぶつかることがあり、上限が system global のためプロジェクト (テナント) 分離ができていないという問題が報告された。

私がバグフィックスを手伝っている OVS native firewall の話もでたが、実際に使われてるの? といった質問がでた程度であった。他に、エージェント数が多い時 (1,000以上) に問題があるといった話があったが、バージョンが古いのではないのかといった反応であった。関連するバグとして、https://bugs.launchpad.net/mos/+bug/1494416 が挙げられていた。

 

Security: Static Analysis of Python with Jenkins for OpenStack

Bandit という Python コードのセキュリティチェックをするプロジェクトがある。Wikiページ (https://wiki.openstack.org/wiki/Security/Projects/Bandit) の説明や、そこからリンクされている去年のバンクーバーでのサミットの発表動画が参考になる。

今回の発表での新しい点は、Bandit が Jenkins と連携して CI job として動くようになったことである。例えば以下のような python-keystoneclient のテスト結果等で確認できる。
http://logs.openstack.org/44/407844/3/check/gate-python-keystoneclient-tox-bandit-ubuntu-xenial/7b8bff3/

 

Nova: Cells v2

Cells v2 の話を最初に聞いたのはちょうど 2 年前のパリでの Design Summit で、時間が経って Cells v2 の実装もだいぶ進んできているようである。今回参加したセッションでは、いくつかの細かい話題が議論されていた。
最初の話題はスケジューラである。現在の実装では、インスタンス作成時に nova-api が Instance オブジェクトを作るようになっているが、Cells v2 では Instance は各 cell DB に収容する必要があり、nova-api は代わりに BuildRequest オブジェクトを作成するようになる。nova-api は conductor を介してスケジューラを呼び、その先で確定した cell の DB に Instance オブジェクトが作成されるようになるといったことが説明された。詳細は以下の spec に書かれている。
https://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/cells-scheduling-interaction.html

また、毎度おなじみの list instances 問題も議論された。list instances では各 cell からの情報をまとめて REST API レスポンスとして返す必要がある。それだけなら各 cell からの情報をマージソートして返せばいいのだが、API が pagination をサポートしているのでそのソート結果の N 行目から M 行分返したりなどどやっかいな処理を実装する必要がある (APIコール間にインスタンス数の変化があっても破綻なく動かないといけない)。短期的解決として Python の merge sort でとりあえず動くものを作るということになった。長期的には searchlight (https://launchpad.net/searchlight) という Elasticsearch ベースのものを使うことになるようである。

また、今回のサミットでは Cells v2 の枠はもう1つあり、そこでは Quota の問題が話し合われたようだ。

 

Neutron: Nova/Neutron Cross-Project Session

Nova と Neutron で共通する話題を扱うCross-Project セッションは 2 コマあった。
1時間目は、ライブマイグレーション時の portbinding 問題が主に話された。VM のライブマイグレーション時には最終的に移動先で仮想ネットワークインターフェイス (vif) を作成してネットワーク接続の移行をする必要があるが、現状のコードではその vif の処理は最後に行われるようになっている。そのため何らかの理由で Neutron の vif 移行処理が失敗すると VM は移動しているのに vif が使えないというお手上げ状態になってしまう。解決策として、実際のマイグレーション処理を行う前に移動先の vif 処理をやっておくという案が Neutron ML2 ミーティングで大分前から提案されており、Neutron だけでなく Nova 側の変更も必要なので Cross-Project セッションで議論された。会場では Nova から Neutron への REST API をどうするか (URIの名前をどうするか等) で盛りあがっていた。Neutron 側および Nova 側の変更点の spec はそれぞれ以下の通りである。本記事の執筆時点ではまだ作業途中である。

2 時間目は os-vif と nova-network 等が話題となった。vif の plug/unplug の処理は Neutron のためのコードが Nova に置かれている形になっており、os-vif ライブラリとして Nova の外に出して解決しようという方針は決められていた。
https://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/os-vif-library.html

Newton リリースでは OVS と linuxbridge の plug/unplug 処理は os-vif に切り出せたものの、他の vif types の処理は未だ os-vif に切り出せていない。また、os-vif がサポートする vif type を Nova と Neutron の間でネゴシエーションするようにするといった方針が説明された。

nova-network は OpenStack の初期からあるネットワークの実装で、散々議論した挙句ようやく Neutron に移行できたのは既報の通りである。今回は、遂に nova-network のコードを消そうかという話をしていた。そのために Nova の 3rd party CI は nova-network ではなく Neutron を使うように直さないといけないと言われていた。ただ、Cells v1 が Neutron をサポートしていないので、Cells が v2 になるまでは消さずに残すことになった。

 

Neutron: Completing the Newton backlog

最新リリース (今回は Newton) までに開発する予定だったが間にあわなかった Blueprint について、どうするかを話しあう毎度恒例のセッションである。Neutron の Blueprint は優先度 High と Low の 2 種類に分けて管理されているが、Newton に間に合わなかったもののうち、優先度 High のものは 1 つ (Diagnostics of Neutron components) を除いて順調で Ocata に入る見込みであるなどと各担当者が報告していた。

Ocata は開発期間が短いので新規開発は基本的にやらない方針であるが、2 つほどこれはやっても良いなどと話していた。また、担当者がいるが活動が行われていないバグが多くあるとのことで、活動のないバグ担当者は外すという方針が説明された。担当欄を空欄にすることで他の人がついて全体としてバグの処理ペースが改善できるのではないかという目論見のようである。

 

Neutron: Neutron Agents: Retrospective and Next Steps

OVS Agent の話題である。最初の話題は、Newton リリースで ovsdb_interface および of_interface のデフォルトが CLI ドライバから Python ネイティブ実装に変わったことであった。ovsdb で性能が出ないという話や、of_interface で多少の非互換性があるといった問題が報告されたが、特にネイティブ実装に重大な問題は起きていないようで、of_interface に関わった私としてはほっとした。古い CLI 実装は Pike で消される予定である。次に、OVS Agent の実装のリファクタリングについて、いつかやるべきである事はみんな認識しているものの、やる人がいないし他にする事もあるので、取りあえずはやらないといった話をしていた。

また、compute node 間に ARP パケットを流さずにローカルで ARP を解決する L2pop という機能があるのだが、その実装が mechanism driver であるために困った事になっているので (Kevin Benton 氏が) 普通に実装し直すという事になった。以下のバグ報告などが参考になる。
https://bugs.launchpad.net/neutron/+bug/1630981

 

Neutron その他

上記以外のセッションでは以下の事が話題となっていた。

  • ロードバランサ実装の neutron-lbaas は Octavia プロジェクトに移行して終了させる。
  • Neutron のテストコードについて， Ocata は Stabilization サイクルだから改善に協力してほしい。
  • neutron-lib は Deprecation サイクルをやめることで開発スピードを上げる。neutron-lib を使っている Stadium プロジェクトは各自 neutron-lib の変化を注意して追従するように。

まとめ

キーノート 2 日目でも言及されていたが、次回サミットから Design Summit は基本的に PTG という別のイベントとして開催される。分離に至る論点の 1 つとして、メインの OpenStack Summit はリリース後しばらく経ってから開催したい一方、Design Summit は時間を無駄にしないようにリリース直後に行いたいというものがあった。OpenStack Summit は大規模イベントで会場の予約の都合上日程を動かせないため、上記の制約を満たすために Ocata リリースサイクルを短縮することになり、Ocata サイクルは通常の 6 ヶ月ではなく 4 ヶ月しかない。そのため開発項目も少なめになっており、Neutron では特に議論を呼ぶ話題もなくサミットは淡々と進んでいた。

 

次回の OpenStack Summit は来年 5 月にボストンで、初となる PTG は 2 月にアトランタで開催される。