OpenStack Summit November 2014 Paris出張報告

Copyright©2014 NTT corp. All Rights Reserved.
OpenStack Summit November 2014 Paris
2014年12⽉4⽇
NTT ソフトウェアイノベーションセンタ
Copyright(c)2014 NTT Corp. All Rights Reserved.

2Copyright©2014 NTT corp. All Rights Reserved.
出張スケジュール等
■⽇程/場所/総参加者数
⽇時：2014/11/03-07
場所：Palais des congrès de Paris
(メインカンファレンス)
Le Méridien Etoile
(デザインサミット)
主催：OpenStack Foundation
参加者数：4600名弱
コマ数：メインカンファレンス 278コマ，デザインサミット 184コマ

• Integrated
• Swift (Object Storage)
• Nova (Compute)
• Glance (Image Service)
• Keystone (Identity)
• Horizon (Dashboard)
• Neutron (Networking)
• Cinder (Block Storage)
• Ceilometer (Telemetry)
• Heat (Orchestration)
• Trove (Database Service)
• Sahara (Data Processing)
• Incubation
• Ironic (Bare Metal Provisioning)
• Zaqar (Queue Service)
• Barbican (Key Management)
• Designate (DNS Service)
• Manila (Shared File Systems)
本⽇の報告
• Etc
• Oslo (Common Libraries)
• TripleO (Deployment)
• Devstack
• Tempest (Integration Test Suite)
• Documentation
• Topic
• Case Study
• SICからの発表
• NFV
• Upgrade
• Container
主要プロジェクトの動向やSICの取組などをご報告します．

Horizon (Dashboard)

• プロジェクトの動向
• デザインサミットでの議論は，運⽤上の⾜りない機能/弱点の把握，UXの改善
，Keystoneとの連携，クライアントでのデータのもたせ⽅，カスタマイズの
簡便化など
• メインセッションでも，カスタマイズの簡便化などが注⽬をあびていた．
Horizon (Dashboard)

【Conference】Extending The Pane of Glass: Building Horizon Panels for
Non-OpenStack Applications
■セッションの概要
• Horizon を拡張して，OpenStack以外のアプリケーションを⼀緒に操作できるす
る⽅法の紹介とデモ．
• 発表者3名とも HP Helion 開発者．
■主な議論
・Horizon拡張には，全く別のGUIを作るアプローチ, OpenStack horizonのコー
ドをあちこち書き換えるアプローチ，プラグインの仕組みで拡張するアプローチ，
がある．
・メンテナンスの容易さを考慮するとプラグインの形で拡張するのが⼀番インパク
トが⼩さいため，その提案とデモを⾏った．デモはWordPressの操作メニューを追
加する例だった．

Ironic (Bare Metal Provisioning)

• Ironicとは？
• Nova の物理サーバ⽤ドライバを準備し，プロビ可能にするサービス
• ２つのユースケース
• VMと同じ⽅法で物理サーバインスタンスをデプロイ
• Triple0(OpenStack on OpenStack)の下回りでOpenStack⾃体のデプロイを実現
• プロジェクトの動向
• Nova からVM同様にプロビする物理サーバ⽤ドライバはJunoで組み⼊れ済．
• Nova-baremetalの機能はおおむねIronicに移⾏済
• 次期Kilo版で正式コンポーネント化されることが決定済．
• ベンダ製品ドライバ毎に実現できる機能差分が⼤きくあり，共通機能部を規定
しようとしている．PTLはKilo版でおおむね動くようになると話していたが技
術者によってそのスピード感には温度差あり．
Ironic (Bare Metal Provisionning)

（１）テナント隔離
• ベアメタルインスタンスのプロビジョニングに合わせて，ネットワーク設定を⾏いテナント毎
に専⽤のネットワークを割り当てる必要あり
⇒テナント隔離（Isolated Network）対応は⼀部のベンダ向けには動作(by RackSpace for Cisco UCS)
（２）ストレージ連携
• スナップショット機能やスナップショットからのテンプレート作成機能の提供
• ベアメタルインスタンスに対してiSCSIディスクを提供
• OpenStack Cinderのような連携をベアメタルで提供できないか？
⇒ Blueprintはあるものの，実装⽅式が難しく検討がすすんでいない．
（３）IPMI機能の提供範囲の決定
• ユーザにすべて提供するとMACアドレス等も偽造可能なケースがあり，機器の管理監視ができ
なくなる
⇒ベンダ差分も⼤きい上，脅威をどこまで想定するか明確化されておらず，取り込みが遅れそう
．
• cf. 別途準備したGUIでIPMI経由で以下の機能を提供するぐらいが現実的か
1.情報確認（各種温度やアラートの有無）
2.電源断/⼊/再起動
3.ハイパーバイザ―操作
【参考】想定要件にむけた課題と状況

【Conference】
Hardware in the Cloud Cleaning Up after Bare Metal Tenants
• 発表者所属：Rackspace
• Baremetalの「廃⽌(Decom)」処理の提案
■主な議論
• RackspaceはIronicベースのサービスOnMetalを提供している
• テナントが解放した物理サーバのHW状態をプロビ可能な状態に戻
す「廃⽌(Decom)」処理が必要
• 具体的にはBIOSのフラッシュなど
• Ironicに「廃⽌(Decom)」状態と処理の実装を提案

Swift (Object Storage)

Swiftとは:
- オブジェクトストレージシステムを提供するソフトウェア
- 2010年にRackSpaceが⽴ち上げ
Swiftの特徴:
- ⾼いスケーラビリティ(No SPOF）
- セルフヒーリング
- REST API
Swiftの得意領域:
- ⾮構造データ(Binary Large Object)
- High Concurrency
Swift (Object Storage)
Swift
写真、ムービー、PDFなどの
アップロード/ダウンロード

プロジェクト動向:
- 海外では商材としてプロダクトインの実績あり(Rackspace Cloudfiles*1、シア
トルの癌リサーチセンター*2など)のStableなプロダクトとして開発が進んでいる
- 主要コントリビュータはSwiftStack、Rackspace、RedHat
- Intel、Seagateらの主導でHWコストを⼤幅に削減するErasureCode機能の導⼊
に向けて開発を進めている
Swift:プロジェクト動向
*1:https://github.com/stackforge/swift3
*2: http://www.slideshare.net/tsuyuzaki/open-stacks-ummitjuno

• EC Overview
• 現在の課題であるセルフヒーリングのアルゴリズムについて議論
• Service Token(Tenant Management)
• 既存のSwiftの認証/ACLの仕組みを調整したい
• Glance等他のOpenStackコンポーネントとの組み合わせた際に（イメージの置
き場など）Swiftと他コンポーネントの認証/ACLを別々に管理したい
• Single Architecture Optimization
• Kinetic, Gluster等の外部リソースとの連携を⾏う際にProxy/Storageの各ノー
ドを同⼀筐体に乗せる構成のことが多いため、Proxy<->Storage間の通信を最
適化したい
• On Disk Encryption
• Proxy-Severでオブジェクトの暗号化を⾏うという提案
• Etag計算の問題、keyをやりとりするためのAPIの策定、どこまでEncryptionを
する必要があるか、など議論点は多く残る
• Python-swiftclient/Ops MeetUp
• クライアントツールやオペレータからの要望を受けるセッション
• 要望例：
• SwiftコマンドでダイレクトにPUT/GETなどのコマンドを使えるようにする
• Tokenのキャッシュ
• ヒアリング例
• Deployment： Puppet, Chef, Ansible
• Ring: partition power growth -> storage policy
• Billing: CeilometerはScaleに難あり、プロプラかsloggingが主流
Swift: Design Summit Sessions
ホット
中長期
運用

• Docker meets Swift (from IBM)
• Swift（主にStorageServer)にDockerコンテナをデプロイしてBLOBに対して必要な情
報を加⼯できるようにする、という試み
• メリット：
• ポータビリティがよい
• Middlewareのようにクラスタ全体へのデプロイを必要とせず、個別に使うことができる
• 処理がコンテナ単位のため、KeyManagementのようなセキュリティ⽤件の必要な場合にも対応
可能
• 例：
• メタデータ付ビデオで⾳圧が⾼いビデオだけ抽出して⾳圧調整をかけるアプリ
• ⾳圧情報のメタデータだけをコンテナ上で切り離してGETできるようにすることで、ビデオ全体
の読み込みを減らす
• https://www.openstack.org/summit/openstack-paris-summit-2014/session-
videos/presentation/docker-meets-swift-a-broadcaster-and-39-s-experience
• Using OpenStack Swift for Extreme Data Durability（from
eNovance and Cloudwatt)
• Swiftの仕組み、Region追加時のマイグレーション、Durabilityの計算の仕⽅などにつ
いて、SwiftへのContributing事例なども組み合わせながらの紹介
• eNovanceのChristianとはSwift Hackathonの時点からDurabilityの計算の仕⽅につい
て議論を進めており、発表中でもNTTとの協⼒関係を強調
videos/presentation/using-openstack-swift-for-extreme-data-durability
Swift: General Sessions

Nova (Compute)

■背景
NovaはOpenStackの主要モジュールであるが、⼤規模にスケールさせる
ための機能などに課題があり、⽐較的⼤きな変更が予想されるため注意が
必要
■注⽬議論
• Cell（⼤規模スケールさせるための構成分割機能）
• 現在のCellはリージョン全体に跨る参照機能やAZの対応など、不⾜機能が多く
、ユースケースが絞られる。
• 現在のCellの機能を拡充するか、新しいアーキテクチャのCell機能を新規実装
するかどうか議論が⾏われた。
• 議論の結果、新しいアーキテクチャのCell機能（仮称：Cell v2）の開発が決
まった。
• 既存のCell機能からCell v2への移⾏のパスは提供されない可能性が⾼い。
• 既存のCell機能がdepricateになるかは不明（結論は出なかった）。
Nova (Compute)

Nova (Compute)
■Kiloへのロードマップ
http://specs.openstack.org /openstack/nova-specs /priorities /kilo-priorities.html
• 今回のサミットでは以下の項⽬に重点的に取り組むこととなった。
• cells v2
• Objects（RPCでのObject利⽤）
• Schedulerの外だし
• API(v2.1, microversions)
• nova functional testingの実施
• nova network migration（Neutronへの移⾏）
• no downtime DB upgrades
• バグのトリアージ（800以上あるバグの対応）
• CI（特にthird party CIの強化）
• KiloでBlue Printを実現するためには原則Kilo-1のマイルストンまでにSpec
が承認されている必要があることとなった。（例外的にはKilo-2まで。）

Glance (Image Service)

■背景
Glanceは⽐較的安定しているプロジェクトで⼤きな機能追加はあ
まり⾏われないが、イメージ以外のものの情報を保有するような議
論(Artifact)も⾏われており今後ユースケースの拡⼤が⾒込まれる
■注⽬議論
• Image Conversion
• バックエンドの制約に合わせてimageフォーマットを変換してあげる。
• Imageの中⾝を⾒てフォーマットを確認するようにする。
• Artifacts
• Glanceは現状Imageを保有するサービスだが、Heatテンプレートのように他
のプロジェクトでも管理保有する必要のあるオブジェクトが出てきており、こ
れらを⼀括管理するようにするための機能
• Metadataを管理し、検索や位置の特定を⾏う
• DBスキーマやAPIなど具体的な提案まで⾏われており、このままGlanceで実
施するか、別プロジェクトにするかなどが議論。
• Novaのglance api v2サポート
• NovaはまだV1のみのサポートだが、Kiloまでに対応される⾒込み
Glance (Image Service)

Neutron (Networking)

■背景
Neutronは仮想NWを構成する主要モジュールの⼀つであるが、多く
のベンダによる機能追加で規模が膨れた結果、品質低下を招き、
Icehouseでは機能追加を⾏わずに品質安定化に注⼒してきた。アーキ
テクチャ変更含めて今後の動向への注視が必要な状況
■セッションの全体概要
• ⼤きくなり過ぎて機能追加やメンテナンス
が停滞しているNeutronの再構築議論が
⼤半を占める
■注⽬議論
• レビュープロセス⾒直し
• サードパーティテストの強化
• ベンダプラグイン、ドライバの分離
• サービスプラグインの分離
• REST、RPC、Plugin APIの変更
• IPAMの導⼊
• L2agent、L3agent、DHCPagent課題
Neutron (Networking)

• レビュープロセス
• Junoで導⼊されたspecはレビューが回っていなかったため、
specレビューチームを結成し、specのレビューを⾏っていく
• コアの数に対してバグが多すぎるため何らかの改善が必要
• サードパーティテスト
• IPv6のテスト、シナリオテストを含めた全てのTempestテスト
の実⾏を必須化
• ベンダプラグイン、ドライバの分離
• Neutronは半分がベンダのプラグインのコードのため、コアも
ベンダのコードをレビューするのに時間をとられる
• ベンダプラグイン、ドライバをメインツリーから外す提案がさ
れたが様々な懸念事項がある
• メインツリーに残すのはML2+OVSのみという話もあった（
Linuxbridgeはもはやコミュニティで⾯倒を⾒る気があまりな
い印象）
Neutron (その２)

• サービスプラグインの分離
• サービスプラグインの機能がIcehouse、Junoでほとんど⼊ら
なかったことが問題視されて議論が進んだ
• FWaaS、LBaaS、VPNaaSなどを含めてサービスプラグインは
Neutronから分離し、別のプロジェクトとして管理する
• 他の提案(Tacker, MPLSVPN, Flavors, QoS)もサービスプラ
グインとして管理される可能性がある
• REST、RPC、Plugin APIの変更
• REST⾮同期問題やレスポンスコードを考えなおす必要がある
• RPCのlive upgrade時のバージョン問題も議論された
• RPC周りは処理が複雑化しているので開発者向けにドキュメン
トを整備する
• Plugin API v3を作成し、Pluginもv3形式を作ることで合意
• ひな形をKiloまでに作成する
Neutron (その３)

• IPAMの導⼊
• 外部IPAMを使うための議論
• 同期と⾮同期どちらが良いか。Neutronの同期/⾮同期問題
• そもそも今のNeutronのL2/L3の考え⽅⾃体がおかしいとの議
論も
• L2agent、L3agent、DHCPagentの課題
• 新しくDVR機能が⼊ったものの、⾊々と問題が残っている。サ
ービスプラグインが使えない、VLANが使えない等の残課題
• DHCP agentのスケジューラにLeastスケジューラを追加する
Neutron (その４)

• Radware、Rackspace、A10 peopleによる
Neutron LBaaS解説。
videos/presentation/load-balancing-as-a-service-v2-0-juno-and-beyond
• LBaaSv1は現状利⽤可能だが、スケール、HA機能がなくPoC
レベル
• v2はkilo向け（スケールする予定）、v1とv2のモデルの違いが
紹介された
• Octavia（HaproxyをVM化したもの、スケールする、HA、
LBaaSv2機能サポート）に関してはkiloではなく開発数サイク
ルが必要。
• 今後の計画：現在v2はコード的にはfeature branchとして
Neutron本体からは分かれているが、kiloでマスターにマージ
する計画。
Neutron (その５)

Cinder (Block Storage)

■背景
・CinderもNeutron同様にベンダードライバの占める割合が多く
なってきており、ドライバの品質担保が課題となってきている。ま
た、プロジェクト内で唯⼀TaskFlowの実装が進んでおり、
OpenStack全体の品質向上に向けた指針となっている。
■注⽬議論
• オーバーコミット対応
• Thin provisioningでオーバーコミットする際に利⽤率を管理できる機能
• Task flow関連
• 現在⼊っているCreate flowを充実させる。Atomic state定義とチェックロ
ジックを実装することでタスクを細分割させるための仕組みを実装。
https://wiki.openstack.org /wiki/Summit/Kilo /Etherpads#Cinder
• 品質向上
• 新機能を⼊れる前に現在のコードをrefactoringする意識が⾼い
• 新ドライバ導⼊に関するチェックが厳しくなっており、K-1までに出さないも
のは⼊れない⽅針
• 新機能にはPoCが必修になるかも？
Cinder (Block Storage)

• Taskflow関連議論（本session／Unconference）
• https://etherpad.openstack.org/p/cinder-enforcement-of-states
• https://etherpad.openstack.org/p/kilo-cinder-meetup
• 本セッション上では、Codeはこのままで外さないことで合意
• Unconferenceでも議論され、Taskflow適⽤に関しては、CinderのAPI
create-volumeに初めて適⽤されたが、その後他のAPIへの適⽤が進まな
かった。しかし、今回のSummitで、Yahoo社、NTT Data,Inc.社以外に
Redhat社もコントリビュータとして⼿を挙げた。
• [今後]delete-volume、atache-volumeへの適⽤が進む⾒通しとなった。
• [所感]⻑期議論であることには変わりないが、機能⾃体は良いとは認識しつ
つも、誰も⼿を挙げない（進まない）状況から好転した。
• Nova Tasks API （Unconference）
• https://etherpad.openstack.org/p/kilo-nova-meetup
• Nova全体のレビューが逼迫しており、なかなかAPI周りが整備されない状
況だったが、今回の Nova unconference において、 API への
Microversionの実装タイミングに合わせて、Tasks APIの実装も⾏おうと
いう予定が⼊れられた。
• [今後]NTTは、提案者のRackspace社活動に対してレビュー等で協⼒し、
マージされるように活動する。
• [所感]毎度Nova API開発者が更新系（特にreboot）のために導⼊を試みる
が、ギリギリ⼊らなかった。今回マイルストンから落ちはしなかったが、
他のAPI実装に依存するので、kiloでも遅めになる可能性がある。
Cinder （その2）

Ceilometer (Telemetry)

■背景
・Ceilometerは性能・スケール課題が指摘されており、Junoに向けて性能改善の
取り組みが⾏われてきた。Junoでの到達点を調査した
■注⽬議論
・Ceilometerと時系列データ管理モジュールのGnocchiをKilo-1から統合し、同
⼀プロジェクトとして扱うことで性能改善を図る。
・例外処理が不⼗分であることが指摘されており、Kiloでは改善される部分が増え
る⾒込み。
例) ポーリングが失敗する場合のハンドリング
・Monasca（Monitoring-aaS)とのコラボレーション
可能性のセッションが設けられたが、特に進展はなく、
差分の議論に留まった。
Ceilometer (Telemetry)

Heat (Orchestration)

■背景
・Heatはリトライや異常系処理が不⾜しているため、ワークフロー機能の
追加や復旧機能などがJunoに向けて議論されてきた。その到達点を探る。
■注⽬議論
• Icehouce から⼤きな開発項⽬として実装が進んでいる現場復旧機能
(stack-convergence) について、PoC の作成が済んでおり、開発者
間での質疑応答のセッションが開かれた。
• 資源の復旧⽅法の設計は終了しており、Juno にて仮実装が進んでいる。
• 復旧時に資源間の関係性を管理する仕組みの議論が⾏われており、Kilo
に向けて設計が完了すると予想される。
• Workflowエンジン（Mistral）との連携については進んでいない印象
Heat (Orchestration)

Trove (Database service)

■動向概要
Icehouseから正式プロジェクト化されたが、機能や品質が不⼗分であ
まり注⽬されてこなかった。Juno以降での機能追加や品質向上による
利⽤動向が注⽬される
https://www.openstack.org /summit/openstack-paris-summit-2014/session-
videos /presentation/everything-you-wanted-to-know-about-trove-but-didn-and-39-t-
know-whom-to-ask
■注⽬内容
・他のOpenStackコンポーネントとの連携
・他のプロジェクトに⽐べコードの成熟度が⾜りず、共通モジュール
の利⽤などが進んでいない。Incubation時代のコードも残っている。
・試験の強化
・Kiloに向けては、MySQL Cluster(Galera)サポートやコードの整理
、利便性向上のための機能以下などが予定されている（次項）。

http://www.slideshare.net/tesoracorp/amirth-kilotrove4

Manila (Shared File Systems)

■動向概要
Manilaは共有ファイルサービスを提供する機能
インキュベーションプロジェクトであり⼀般講演で概要説明などを実施
主な参加企業：EMC, NetApp, RedHat, Mirantis, IBM
■主な内容
・構成はCinderに近いが、複数のVMに対するファイル共有が可能であ
り、アクセス管理機能を提供する（現状はIPアドレスのACL）
・現在NFSとCIFSに対応
・ManilaからVM, NW, Volumeを作成してファイルサーバを構築
・Horizonからテナントごとの共有ファイルストレージ構成を作成可能
であり、VMからマウントすることが可能（現在は⼿動マウント）
・ファイル共有するVMはプライベートネットワークで接続される
・EMC, NetApp, RedHat(Gluster-NFS), IBM(GPFS)各社がドライ
バを提供
Youtube video link: https://www.youtube.com/watch?v=fR-X7jbG5QM
Manila (Shared file systems)

Sahara (Data Processing)

• 概要
• データ分析を⾏うクラスタのプロビジョニングおよびデータ分析
ジョブの管理を⾏う
• Junoリリースより，統合プロジェクト⼊り
• 機能
• データ分析クラスタの構築・リサイズ・削除
• Hadoop (Hive, Pigを含む): Vanilla 1.2.1 / 2.4.1, HDP 1.3.2 / 2.0.6, CDH5
• Spark (Juno版より): CDH4+Spark 0.9.1 / 1.0.0
• 分析ジョブの投⼊や実⾏状態確認
• MapReduce/Hadoop Streaming/Hive/Pig/Spark/Javaアプリ
• HorizonのData Processing(データ処理)タブより操作できる
• Anti-Affinity
• Swiftのデータローカリティアクセス
(ComputeNodeとSwift object/proxy-server相乗り時)
Sahara (Data Processing)

• 他のOpenStackプロジェクトとの連携
• Heat
• クラスタ構成に合わせたVMの起動
• ネットワークリソースの設定 (Floating-IPなど)
• Keystone
• ユーザ認証
• TRUST+Domainを⽤いた，Swiftアクセス権限移譲
• Cinder
• HDFSの永続化に利⽤可能
• Nova
• Anti-Affinityの実現に
スケジューラヒントを利⽤
• Swift
• ジョブバイナリや
分析対象データの⼊出⼒先
Sahara: Data Processing

• Elastic Data Processing (EDP) features
• Hive/Spark対応が不完全  Hiveが動くように＆Swift連携
• ドキュメントや異常系試験が⾜りない
• 分析対象データのURLを毎回⼊⼒するのは⼤変
 DataSourceの利⽤を拡⼤
• swift://container-name.sahara/object-name
• Sahara UX discussion
• クラスタのテンプレート作成＆クラスタの起動に66クリック+16⼊⼒
 ウィザード形式＋デフォルトテンプレートで操作数を減らす
• テストが⾜りない＆UIテストが無い
 Horizonに合わせて増やしていく
【Design Summit】Sahara

Tempest (Integration Test Suite)

• Tempestとは？
• QA (quality assurance) プロジェクトの4サブプロジェクトのうちの1つ
• Tempestは、OpenStackの外部インタフェース(主にAPI)の機能試験・シナ
リオ試験を提供し、後⽅互換性を保証する役割を持つ
• その他、Grenade (アップグレード試験)、Devstack (開発⽤OpenStack
デプロイ)、Infra (CI/CD基盤構築・運⽤) でQAは構成される
• Tempestは、OpenStackプロジェクト全体で3番⽬に多いコミット数
• ユースケース
1. OpenStack OSSコードのパッチ作成時のCI/CD⽤試験
2. 各社のOpenStackクラスタの納⼊試験や各社個別のCI⽤試験
Tempest (Integration Test Suite)

【Design Summit】Tempest
■QAプロジェクトの動向
• テスト数が充実した⼀⽅、テストに時間がかかり過ぎ、CI環境の負荷が⾼まってかえっ
てテストが不安定になっている問題に対する対応
• 各社のOpenStackクラスタに対する試験実施(ユースケース２)の複雑さに対する対応
■セッション内容 (7つのQAセッションのうち、4つがTempest)
• Gap analysis for using Tempest in production (NES, 井川さん)
• ユースケース２に対して、どんな困難さがあるかをブレインストーミング
• 結論：コンフィグの多さ(>270)、Admin認証必須、不要試験スキップのカスタマイ
ズ性、ドキュメント不⾜などがリストアップ
• Tempest scope in the brave new world (HP, Matthew Treinish)
• 試験時間の短縮のため、単⼀プロジェクトのAPI試験を各プロジェクトへ移⾏する⽅
針の提案
• 結論：全てのAPI試験の移⾏はしないが、その範囲はやりながら検討。また、新規機
能試験がTempestに提供される動きに対しては拒絶しない。
• Tempest-lib moving forward (HP, Matthew Treinish)
• API試験の移⾏の簡易化、及びコードのメンテナンス性の向上に向けた、Tempestの
機能モジュールのライブラリ化(Tempest-lib)の提案
• 結論：まず最初に移⾏するコードのスコープ、⽅法論、実作業分担の決定
• Future auth interface design for Tempest (NTT, 森⽥)
→ 次スライド

■ 議論内容
• Tempest機能ライブラリ化のための”認証
連携箇所”に対し、以下を議論
• 移⾏対象のソースコードの整理
• 認証インタフェース将来像の議論
■ 発表の狙い
• NTTの提案する「認証機能と連携しないSwiftに対するTempest試験」機能の
Tempest-libライブラリ化に向けた、認証仕様の設計提案
• NTTが試験実施をする際のTempest設定／拡張の複雑さを軽減
• 認証無し試験のプロプラコードの保守稼働をコミュニティに移管
■ 議論結果
• ライブラリ化対象コードと、移⾏時のリファクタリングの原則は了解
• SIC提案内容の効果には⼀定の理解は得たものの、既存コードを壊す可能性が
あるとPTLが判断。優先度⾼い作業であるTempestライブラリ化がコミュニテ
ィで完了後、改めて、SIC提案の認証インタフェース改善議論を開始する
■ 今後のアクション
• パッチ作成・レビューを通してコミュニティのTempestライブラリ化作業を加
速させ、認証インタフェース改善議論を早く開始出来るようにする
【Design Summit】
Future Auth Interface Design for Tempest

Documentation

■背景
・各種マニュアルやAPI仕様書などOpenStackドキュメントは整備が進んでいる
⼀⽅でメンテナンスが⼗分できていない。SICでもAPI仕様書の不⾜部分を補った
独⾃仕様書を作成しており、それらをコミュニティに還元する提案を⾏う予定
■主な議論
・documentain の PTL (documentation team の取りまとめ) へ提案したと
ころ、早くコミュニティのドキュメントへアップロードして欲しいとの回答を得る
• 後⽇開発者向けメーリングリストでも、コミュニティへのアップロードを
期待している旨のコメントが流される
• ドキュメントをアップデートを⾏うメンバが少ない問題
• コミュニティのドキュメントの記載が少なく、OpenStackユーザへのマニュ
アルが少ない事が問題視されている
• 各社エンジニアがドキュメントを記述しないことが理由となっている
• OpenStackエンジニアはコミュニティコードを更新することが仕事であり
、ドキュメント作成が不得⼿なため、ドキュメント整備を⾏うメンバー（
ボランティア）を増やす必要がある
Documantation

SICからの発表

⼀般講演
1. 夏⽬： “OpenStack Upgrade Without Down
Time”
https://www.openstack.org /summit/openstack-paris-summit-
2014/session-videos /presentation/openstack-upgrade-without-
down-time
ライトニングトーク（vBrownBag)
http://openstack.prov12n.com/vbrownbag-techtalk-schedule-
at-openstack-summit-paris-2/
1. ⽥中： “High Availability for VMs using
evacuate API”
2. 室井：”How to Build a Carrier Grade Cloud – A
RE RE Teck Talk –”
3. サンパト：”How to protect glance public image
in carrier grade cloud”
4. 市原：”Neutron CI Run on Docker”
SICからの発表

NFV関連

背景：ETSI NFVやOPNFVにおけるVIM（仮想インフラ管理モジ
ュール）としてOpenStackの活⽤が期待されており、前回サミッ
トでもNFV subteamが発⾜するなど議論されてきた。
OpenStack側での対応（温度感）を把握し、NFVの取り組みにフ
ィードバックする
• 全体の議論
• 今回のサミットでもセッション数が多く、⼀つのキーワード
• OPNFVの役割やOpenStackがどのように使われるのかという基本的
な議論が多かった。OPNFVでは、KiloでNFVのテストモデルを構築す
る計画をしている
• 課題としては、VMのトランクVLAN対応、⾼速転送のためのDPDK対
応などのパケット処理部分、VMのスケジューリングに関するものなど
のインフラとしての基本機能の議論が多い
• キャリアグレードという⾔葉を使う企業が多かったが、具体的にキャ
リアグレードの指標を説明しているところはなく、イメージ先⾏な感
触であった。
NFV関連の話題

• OPNFV、NFV subteamが考えている課題
• NovaによるVMのスケジューリングの不⾜
• VMのvNICの転送速度
• OVSの転送速度
• IPv6の対応
• 基本的に下回りやNovaに関するものばかりでNeutronに関して
は、それほど多くの要件はない
• NFVに関連性が⾼いServiceVM(Tacker)もあまり重要視されて
いない
• NFVチームはOpenStackにNFV⽤APIをあまり期待していない
• あくまで下回りをOpenStackAPIで作成できれば良く、VMとL2NW
までを提供してもらえれば良いと考えている印象
• DPDK対応やVMのマネジメントが重視されている印象
NFVとOpenStack

• 発表者: Hitachi, Juniper
• キャリアグレードなモバイルのVNFについて検討した
■主な議論
• Hitachiの持つすべてのコア網⽤HWを
VM化してContrailに接続した
• ContrailはHA、セキュリティなどの
重要なキャリア要件を満たしている
• X86のIntel CPUを使って転送速度
160Gbpsを実現
【Conference】Creating a Carrier-Grade Virtualized
Network Function for Mobile Operators Using OpenStack
https://www.openstack.org/summit/openstack-paris-summit-2014/session-videos/presentation/creating-a-carrier-grade-virtualized-network-function-for-mobile-operators-using-openstack

【Conference】
Developing OpenStack as a Framework for NFV
• 発表者: Redhat, Intel, Ericsson
• OpenStackを使ってNFV環境を構築するための活動
■主な議論
• Junoサミット以降、NFVサブチームで
OpenStackへのNFVの要件を議論
• いくつかの必要な機能をマージさせる
ことに貢献をした
• Kiloに向けてVMの中でVLANを付ける
機能やその他まだ必要な機能が多々ある
https://www.openstack.org/summit/openstack-paris-summit-2014/session-videos/presentation/developing-openstack-as-a-framework-for-nfv

【Conference】
Economics of NFV and OpenStack
• 発表者: Ericsson
• NFVを使ってどの程度コスト削減できるか
■主な議論
• 2019年までに順次NFVに以降する
シナリオでコストを算出
• CAPEXはNFV導⼊後すぐには削減効果
がないがOPEXは早い段階で効果がある
• NFV化の完了後、CAPEXは8.7%削減
OPEXは24％削減可能
https://www.openstack.org/summit/openstack-paris-summit-2014/session-videos/presentation/economics-of-nfv-and-openstack

【Conference】
Demonstrating NFV on OpenStack
• 発表者: AT&T, Ericsson
• OpenStackベースのクラウドマネージャーを使ったNFVデモ
■主な議論
• NFVの重要な要件としてHAがあり、
その中でもVMのHAのデモを⾏った
• SIPサーバとして動くVMをホストして
いるマシンをダウンさせると別のホスト
マシンにこのVMが⾃動復旧する
https://www.openstack.org/summit/openstack-paris-summit-2014/session-videos/presentation/demonstrating-nfv-on-openstack

【Conference】
Telekom Deutschlands Approach to NFV
• 発表者:ドイツテレコム
• ドイツテレコムのNFVの検討
■主な議論
• キャリアグレードでNFVを利⽤するなら
品質やHA、セキュリティなど課題がある
• 右図のようにインフラオーケストレータ
からVNFの操作をするのは禁⽌すべき
アプリケーション
オーケストレータ
VNF VNF
Manager
インフラ
オーケストレータ
OpenStack
VNF
https://www.openstack.org/summit/openstack-paris-summit-2014/session-videos/presentation/telekom-deutschlands-approach-to-nfv

• Supporting Telecom and NFV with the Open Source
Ecosystem ?(General Session)
• https://www.openstack.org /summit/openstack-paris-summit-2014/session-
videos /presentation/supporting-telecom-and-nfv-with-the-open-source-ecosystem
• AT&T, Canonicalの発表。
• クラシックなアプライアンスアプローチとNFVの⽐較から始まり、スケー
ルしない問題や、移⾏課題などについてふれた。
• OPNFVを⼀つの例として提⽰。あと、OpenStack NFVコントリビュータ
募集してた。
• [所感] OPNFVが魔法の箱になってるのと、⾃分でバリバリやる気はない
のかなぁ？という印象をなんとなくもった。
• Building an NFV Orchestration Platform with
OpenStack ?(General Session)
• https://www.openstack.org /summit/openstack-paris-summit-2014/session-
videos /presentation/building-an-nfv-orchestration-platform-with-openstack
• Tata Consultancy Servicesの発表。ETSI NFVのリファレンスアーキテ
クチャの話等。OpstとのVNF(Virtual Network Function) オーケスト
レーションの例V1-3（興味のある⼈はどうぞ）提⽰。Code Repo提⽰あ
り。
• Roadmapとして、今後、スケジューリング機能、HA、ポリシードリブン
なオーケストレーション、スケール等が挙げられていた。
• [所感] それなりに⼈はいたが、特に質問もなく。ETSI仕様をとうとうと
説明していた印象。
【Conference】その他NFV関連

Upgrade関連

■背景：OpenStackを商⽤で利⽤する場合、無停⽌でのアップデートは必要要件であるが、
これまでOpenStackではあまりアップデート⼿順が議論されてこなかった。最近商⽤利⽤や
サポートベンダが増えるに従い、アップデートに関する議論が活発化してきた。
プロジェクト内ではNovaの対応が進んでいるが、他のプロジェクトでも議論がされ始めている
ことから、最新の動向を把握し、アップデートに備える。
■Upgrade（Live Upgrade含む）のセッションが多かった
• General Session 6件
• Headline Panel: Global Enterprise IT Companies Supporting OpenStack
• Intelの⼈が、IntelはLive Upgradeの実現に継続的に投資しているとの発⾔あり。
• Pumphouse: Workload Migration and Rolling Upgrades of OpenStack Cloud
• OpenStack Upgrade Without Down Time 【NTT発表】
• The Road to Minimally Impacting Live Upgrades of the Rackspace Public Cloud
• Long Periods of Boredom Punctuated by Moments of Terror'- Upgrading Live Openstack Clusters
• Upgrading in Place from Grizzly to Icehouse: A Cautionary Tale
• Design Summit Session 8件
• Ops Summit: Architecture Show and Tell - Upgrades Special Edition(Ops)
• Consistent Approach to Upgrades and Versioning(Cross Project)
• Nova Objects Status and Deadlines(Nova)
• Cinder Rolling Upgrades(Cinder)
• Objectify Cinder(Cinder)
• Heat Upgrades (testing, status, zero downtime)(Heat)
• Ops Summit: Upgrades(Ops)
• Nova Upgrades and DB migrations(Nova)
Upgrade

【General】Pumphouse: Workload Migration and
Rolling Upgrades of OpenStack Cloud
 Mirantisが発表
 Pumphouseというツールを使⽤したUpgradeに関するセッション
 別環境（新環境）を⽤意して徐々にUpgradeを⾏なう⼿法
 Pumphouseは旧環境のVMのメタデータを吸い上げ、新環境でVMをrecreate
する。
 旧nova-computeノードから新nova-computeノードへVMを「移す」。
 ダウンタイムの発⽣がある（＝ユーザへの影響あり。）

【Design Summit】 Dealing with RPC and DB changes
during upgrade(Cross Project)
■主な議論
• RPC APIにおいてはバージョニングが重要
• パッチのバックポートは、バージョニングやDBマイグレーション
に影響する。
• そのバージョニングを全プロジェクトへの適⽤を広げるため、共
通のライブラリとして「oslo.versionedobjects」が提案されて
いる。
• https://review.openstack.org/#/c /127532/
• バージョニングの代わりにgoogle protocol buffersによる提案
もされているが、実装が複雑になることが懸念されている。

【Design Summit】Ops Summit: Upgrades
■主な議論
• データベース・マイグレーションがあるのでダウンタイムはゼロにはできないので
はないか
• カスタマーにとって何がダウンタイムであるかの定義が必要
• APIダウンタイムは避けられないのではないか
• Pythonライブラリのバージョンも問題となる
• コミュニティのアップグレードガイドは古くなってしまった。
• Nova-networkからneutronへの移⾏はRackspaceが実現した（事例有り）。
• Neutronはアーキテクチャ上の変更が問題
• 例えば、MetaPluginからML2への変更等
• Upgradeの例としてCERNとNTT（試⾏）の例が紹介された

Container関連

• Container概要
• Linuxコンテナ関連のプロジェクトが2つ提案された(Magnum, Kolla)。
• Caoninicalから、LXC管理基盤のLXDの開発が発表された。
• 各プロジェクト/プロダクトの動向
• Magnum: コンテナ管理の抽象化層。全てのNovaインスタンス(VM、物理、
コンテナ)上の、あらゆるコンテナ(Dockerコンテナ、LXC、OpenVZ)に対す
る操作を⼀元的に⾏えるようにすることが⽬的。コンテナ管理基盤
(CloudFoundry、Kubernetes、Mesos)の統合も⽬指している。
• Kolla: OpenStackクラスタのデプロイ機能。DockerとKubernetesを利⽤
してOpenStackクラスタを容易にデプロイできるようにすることが⽬的。い
ずれTripleOにマージすることを⽬指している。
• LXD: LXC管理基盤。Dockerのようなアプリ共有基盤としてではなく、コン
テナの⾼性能という特徴を活かしたIaaSを想定したコンテナ版のハイパーバイ
ザを⽬指している。OpenStackにはLXD向けのドライバが実装される予定。
Container

【Conference】Orchestrating Docker with OpenStack
• 発表者所属：Rackspace
• OpenStackのプロジェクトMagnumの取り組み紹介
■主な議論
• Magnumはコンテナ管理を抽象化する層で、コンテナにとってのNovaと
いった位置づけ
• Havana & Icehouseのイメージマネジメント⽅式の紹介
• 直近は、Dockerコンテナへのポーズ/アンポーズの追加、Cinderとの連
携部分の実装に取り組む
• Design Summitでは抽象化インタフェースをDockerに倣うか否かなど
の議論があったが、まとまらなかった様⼦

【Conference】
Docker All The OpenStack Services
• 発表者所属：Red Hat
• OpenStackのプロジェクトKollaの取り組み紹介
■主な議論
• KollaはOpenStackサービスをコンテナ化するモジュール
• 既存のコンフィグ管理ツールベースのビルドや、イメージベースのデプロ
イ(TripleO⽅式)などの解決法では、デプロイスピードやOSアップデート
時のコスト等の観点から不⼗分
• デプロイスピードはDocker, Kubernetesを,OSアップデート時のコスト
はProject Atomic (OpenShift)を、それぞれ組合せての解決を⽬指す
• 今後はマルチホストネットワーキングなどに取り組む

【Conference】
The New New Thing: Turning Docker Tech into a Full Speed
Hypervisor
• 発表者：Canonical
• LXCを統合管理するソフトウェアLXDの発表
■主な議論
• LXD (lex-dee)はLXCを、既存ハイパーバイザのような使い勝⼿で利⽤可
能にすることを⽬指したソフトウェア
• 例えば、ライブマイグレーション、ポーズ/アンポーズ、スナップショッ
トなどの機能の実現を⽬指す
• ライブマイグレーションのデモ
• OpenStack向けのLXDドライバが実装される予定

OpenStack Summit November 2014 Paris出張報告

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (13)

Similar to OpenStack Summit November 2014 Paris出張報告

Similar to OpenStack Summit November 2014 Paris出張報告 (20)

Recently uploaded

Recently uploaded (9)

OpenStack Summit November 2014 Paris出張報告