はじめに

OpenStack Summit および Kilo Design Summit が 11月3日から 7日の日程でパリ Porte Maillot に位置する Palais des Congrès および周辺会場で開催された。

米国以外での開催は2回目である。ちなみに、Porte 何とかというのは、19世紀にパリが城壁で囲われていたときの出入口の名前の名残である。

Summit 全般

前回のアトランタに続いて、Summit の一般向けセッションと Design Summit の開始日を 1日ずらしたスケジュールとなっていた。開発者も一般セッションに出られるようにするための措置であるが、今回の Design Summit は通りを挟んだ別会場だったので、 Summit 間の移動は若干不便であった。

前回に続き運用上の課題などを議論する Ops Summit もあった。

ヨーロッパ開催ということもあるのか、朝の全員参加のキーノートで、ユーザ事例として BMW や CERN 等のヨーロッパの例が多く取り上げられていた。

Design Summit

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

初日はプロジェクトを横断する話題を扱うプログラムだった。
非公式な議論用のプロジェクト毎の丸机が広間に置いてあったのは、前回のアトランタと同様である。

今回の新しい試みとして、最終日は “Contributers Meetup” という名前でプロジェクト毎に集まり、細かいスケジュールを事前に決めずに議論する日になっていた。

 

 

 

cross-project

  • How to Tackle Technical Debt in Kilo
    議題は、直さなきゃいけないんだけど直せていないものが溜っていてどうしようか? といった意味である。openstack-dev メーリングリストでは、Summit の数ヶ月前からこのキーワードでしばしば話題に上っていた。この問題に悩まされているのは主に Nova と Neutron で、司会は Neutron の前 PTL (Program Technical Lead) の Mark 氏であった。

    コードに対するクリーンアップとバグ修正と機能追加のバランスを取りたいが、ベンダーの開発者はどうしても自社製品にかかわる新機能を重視してしまうため、それをプロジェクト運営で改善できないかという議論があった。

    他にも、現状の開発スピードが落ちているのはコードベースが多すぎるためで、ドライバやプラグインを外に出してしまうことで改善できないかといった話題や、外部のライブラリに起因する問題でコードの改善が妨げられている (eventlet のために python3 移行が進まないなど) といった議論がされていた。

 

  • Approaches for Scaling Out
    スケールアウトは関心が高いようで参加者が多かった。大量の物理サーバを 1つの OpenStack で管理するのはいろいろ問題があるので、どういう方法があるかという議論である。

    まず最初に Rackspace ではどのように運用されているかの説明があった。複数 region に分かれており、各 region に複数の nova-cell があるといった説明がされていた。

    次に Huawei の人達が作った Cascading というものの説明があった。これは複数 distribution/version の OpenStack を束ねて 1つの OpenStack に見せるというもので、1.5万行ほどの実証 (PoC) コードがあり、束ねられたほうの OpenStack の 1つが故障しても残りの部分で動きつづける Fault isolation などの特長があると説明されていた。

    それに対して、このような Multicloud や Federation といったものはクラウド間の同期の問題があって難しいのでは、という会場の声があった。

 

Nova

  • Cells
    Nova の最初のセッションは cell についてであり、 Nova コミュニティにおける関心の高さが感じられた。まず、 cell の現状について、cell で使えない Nova の機能があったり、コードが複雑すぎたり、CI テストが十分にされていない、また、親 cell と 子 cell の DB 間の整合性の問題が起きることがあると説明された。

    次に、今後の方針として、このまま開発を続ける A 案と、単純化したものを作り直す B 案が提示され、特に議論なくB案が採択された。

    残りの時間では、現状の cells のコードのテストを追加して壊さないようにすることや、誰が spec を書くか等の細かい事柄が話されていた。新しい cell の実装は cells v2 と呼ばれることになった。

 

  • nova-network migration
    この nova-network から Neutron へのマイグレーションについて議論するセッションは、Nova のセッションとして行われた。朝早いセッションであったことと、Telco Working Group が同時間帯で開催されていたこともあり、Neutron 開発者の参加者は少ないようであった。

    元々このマイグレーション機能は、 nova-parity という名前で Juno での Neutron の重点項目として扱われていたものの一部であったが、様々な問題のため Juno には入らなかった。

    Kilo では、 Juno で計画されていたものとは違うやり方で進めるようである。詳しくは openstack-dev に流れたメール (http://lists.openstack.org/pipermail/openstack-dev/2014-August/044106.html) に書かれているが、Neutron から nova-network へ REST API を転送する proxy 機能を追加し、Neutron に nova-network の状態を理解する新しい L2 agent を実装することで、2回の短い nova API の停止を伴う migration として実現するという計画のようである。

    セッションでは淡々と作業方針が説明されていたが、おそらく結構大変な仕事になると思われる。

 

Neutron

今回のプログラムは、 API の整理やプロジェクトの分割といった話題に多くの時間が割かれていて (この 2つの話題だけでスケジュール 6枠分が消費された)、新機能に関しては Lightning Talks や Contributers Meetup で少し話されている程度であった。ちなみに、現 PTL の Kyle 氏は諸事情により欠席だった。

  • Kilo Dev Process and Procedures
    Neutron の Design Summit は、この Kilo Cycle での開発の進め方についてのセッションから始まった。議論しやすいように前方の椅子を丸く並べ換え、前 PTL の Mark 氏を囲んで開始された。90人ほどが集まり、その後も続々と人数が増えていった。開発プロセスへの強い不満からか、地味な話題のわりに盛況であった。

    以下のような雑多な問題について議論していたが、あらかじめ内輪で結論が出ていたものが多かったためか淡々としていた。

    – Contribution の敷居が高い問題
    パッチを提出してもなかなか Review を受けられないなどの、よく挙げられる不満について、Neutron を分割することで解決しようという方針が内輪で決まっていた様子である。

    – 役割を終えた、または役割のはっきりしない Subteam の整理
    Neutron には L3、IPv6、DVR、ML2 など多様な Subteam がある。その数が多すぎて開発者の負荷になっているという問題について話し合ったが、特に結論は示されなかった。 

    関連して、Summit 終了後に各 Subteam の目的がまとめられた。neutron-drivers によって subteam の存続が議論される予定である。
    参考: https://wiki.openstack.org/wiki/NeutronSubteamCharters

    – Incubator, feature branch について
    新機能を API 等が安定するまでは別リポジトリー (Incubator) や別ブランチ (feature branch) で開発するという方向性について、Neutron を分割することで解決しようという方針が内輪で決まっていた様子である。

    – CI の requirement
    Neutron のリポジトリー内にあるドライバー等のベンダー依存コードに対して、各ベンダーが CI を提供する事が要求されている。そのテスト内容について、stable branch にも master と同水準のテストを要求することになった。

    最も使われている core plugin の一つである linuxbridge に CI が無いという問題提起があったが、特に解決は示されなかった。

 

  • Neutron Split: Vendor Plugins and Drivers
    数ヶ月前から openstack-dev メーリングリストでしばしば話題になっていた、Neutron の運営がうまくいっていないから分割してしまえという話である。スケジュールを 2枠使って議論された。
    背景としては、Juno 開発サイクルを通して明らかになった人的リソース (特に core 開発者の時間) の不足がある。現在 Neutron には 20以上のプラグインと 10以上の ML2 メカニズムドライバがあり、これらのベンダーコードのパッチそれぞれについて core 開発者 2人がレビューすることは大きな負担になっているようである。

    以下で述べるように分割することに懸念はあるものの、他に core 開発者の時間をひねりだすような案もないため、分割することは Summit 前から既定路線といった感じであった。

    対象となるのは、各ベンダーの L2 プラグインと ML2 のメカニズムドライバなどである。 Gate/CI テストや、 DB スキーマや API バージョニングはどうするの かといった議論がされた。また、会場からの声として、別々に開発されると “separation concern”、つまりくっつけてうまく動くのかという懸念の声が上がっていた。それに対し Rackspace の技術者は、 Neutron はライブラリ扱いであり、自社内でテストして壊れたら直しているから別に困らないと発言して会場を驚かせていた。

    Summit 後、この話題は core-vendor-decomposition という blueprint でレビューされ承認された。Kilo の目標では、ベンダープラグインやドライバのコードをまるごと全部追いだすのではなく、vendor integration と呼ばれる以下のものを Neutron 内に残して、ベンダー特有の処理やユニットテストは追いだされることになった。
      – データモデル (DB定義)
      – extension の定義
      – 設定ファイル
      – ベンダーコードをインストールするための requirements.txt ファイル

 

  • Neutron Advanced Services Spin Out
    Neutron の分割の話題は Advanced Services についてもあった。 Advanced Services とは VPNaaS、FWaaS、LBaaS などの L3 より上のレイヤのものを指す。

    議論では、分割することは決定済みで、 PTL や core 開発者の体制について具体的な話がされていた。PTL は Neutron 全体で一人とし、core 開発者は Neutron 本体と各 Advanced Services についてそれぞれ定める (メンバーが重複する事はある) ということになった。

    その他、REST API、DB、サーバープロセスなどを分割する場合の得失などの議論があった。

    Juno Design Summit では LBaaS を分割して Neutron の外でやりたいと言う人達をみんなで宥めていたのだが、半年もすれば状況はすっかり変わるものである。Summit 後にまずは repository を分割しようという話になった。

まとめ

Summit のしばらく前から openstack-dev メーリングリストでは OpenStack の抱える問題がしばしば話題となっており、それらにどう対処していけばいいかという話題が今回は多かった印象を受けた。特に Neutron では、新機能導入にはとても慎重であり、過去の負債を片付けることに集中したいという感じである。
そのため、 Kilo で Neutron に目立った新機能は入らなそうであるが、L 以降で成長軌道に戻れることを期待したい。

なお、 Neutron では、12月8-10日の日程で mid-cycle meetup が行われ、リファクタ関係ではいくつかの進展があったようである。また、advanced services のリポジトリ分割も行われた。

Kilo リリースは 4月30日の予定であり、次回の Summit はカナダのバンクーバーで 5月18-22日に開催される。その次の M Summit は東京で開催される。