OpenStack RallyMitaka Updates ＆ Next-step for Newton

OpenStack Summit Austin報告 (1/2)

Yuki Nishiwaki

About my materialPTLであるMr. Borisが「Overview of Mitaka results and Newton Goals」というセッションで喋って

いたときの資料を貰い、その資料を掻い摘みつつ、日本語の注釈を交えながらスライド

を作成しています。

セッションで実際に使われた資料はこちら: https://docs.google.com/presentation/d/1g5fd2BJXc40yienjCB0Fuc8NaB0e5pQO0XbUHQ1CY0s

General Topic

● Version Trend (Liberty → Mitaka)○ 0.1.1(2015/11/6) → 0.4.0(2016/04/18)

● Dessign Summit Attendees○ 30名程度(Tokyoのときよりは少し多い )

=> 今回のサイクルで各OpenStack ProjectのGateに入り始めて注目度が上がってる？

What is Rally

OpenStack Benchmarking Componet

元々のコンセプト :Benchmarkだけでなく、Deploy -> Test -> Benchmark全てをRallyで実現することで、チューニングしながら質の良いOpenStackクラウドを構築する。

Verify:● Tempestの利用(他のテストツールも使えるようにという

動きが出てきた )● Rallyとしては、結果をどう見やすく管理するか

Benchmark:● C-planeのbenchmarkがメイン

○ Resourceをたくさん作った時のDB/MQの負荷● D-planeも実はfocusに入ってる

○ 各flavorのvmでunix-bench○ 2vm間でiperfの実行

あんまり開発が活発でない● devstack● fuel

みんなの興味はこっち

[1]OpenStack Rally wikiより引用

今は１つのプロセスで全て動いている (実行時に threadは使う)

What is Rally

Now developing

[1]OpenStack Rally wikiより引用 したものを一部変更しものを掲載

Started to change the architecture.

現在: ● RallyはAPI,Deamon(常時起動プログラム )を持

たない１つのアプリケーションとして動作● RPCも使わない● rally-XXXとかない(e.g. nova-api/conductor...)

これから(開発中):● moduleが増えます(rally-XXXができる)● REST API持ちます● Benchmarkを実行するagentが作成されます

○ 複数のagentで分散してbenchmarkを実行できるように

DistributedBenchmark runner

DistributedBenchmark runner

DistributedBenchmark runner

Now developing

Rally Mitaka Updated

Already improved(Common function)

● Plugin関連(Rallyは、全てをPluginとして差し替え可能にしたいという考えがある )○ Switch to plugin base

■ Taskやdeploymentなども同じ基底クラスを継承するように変更

○ Plugin reorganization & docs■ Pluginに関するドキュメントの追加

■ CLIでPluginごとのhelpを出力できるように ($rally plugin show <plugin name>)● Results export mechanism(TokyoのDesign Summitでふと話題になった開発項目 )

○ sampleでfile_systemにexportされるplugingが実装されている

■ これを使うと json formatでtaskの結果が保存できます

○ 自分でpluginを書くことで、結果を thirdpartyツールに送ることもできます。

● DB Migrations: Alembic integration○ スキーマのバージョン管理をきちんとしましょう

○ 「rally-manage」コマンドに、db upgrade/downgrade/revisionが追加

Already improved(Rally verify)

● Specify list of tests to run via file

○ Tempestのテスト名(class path)を羅列したファイルを読ませること

で実行する testを指定することができる

● Tempest results importer○ Tempestの結果(testr)をrallyにimportしてRallyのDBで管理可能

● CI improvements○ CIでRally verifyでtempestのfull setのテストが流せるように

○ verifyのreport htmlも見やすく変更 ● xfail mechanism

○ 失敗することが分かっている testを指定しておいて、その testが失

敗しても成功とみなすように。

● 外部のtempest.confを取り込めるようになりました

Xfail mechanism

● 失敗するテストを下記のように指定: {“test.full.name”: “reason”}● rally verify start --xfail-fail <that_fail>

● 失敗しても、成功と認識される

Already improved (Rally task) 1/3● Better cleanup mechanism

○ 以前までは、pluginの実装によって、 resource prefixの命名規則バラバラだった

■ saharaで使うglance image: rally_sahara_image_<random値>■ novaのsecurity group: rally_ssh_open_<random値>■ keystoneのuser: ctx_rally_%(tenant_id)s_user_%(uid)d

=> prefixがバラバラなので、cleanup処理をpluginごとに書く必要がある・・・

○ 共通モジュールで、名前を生成するように変更し、 pluginで命名規則を統一するようにした

■ Context resources: c_rally_<part_of_task_uuid>_<random_part>■ Scenario resources: s_rally_<part_of_task_uuid>_<random_part>

○ 上記変更により、下記の機能実装が容易になった。 (Newtonまでには、実装される?)■ cleanup specific task resources■ cleanup all rally resources

例:Context Pluginの命名規則

Already improved (Rally task) 2/3 ● Scalability enchantment

○ Runners are returning in async ways results to engine■ benchmarkが最後まで終了しなくても、随時結果を保存するようになった？ (未確認)

○ SLAs are calculated online■ 今までは、benchmark終了時に結果を評価

■ SLAの確認が、リアルタイムで計算できるようになった。

○ Reports are using streaming algorithms■ benchmarkが最後まで終了しなくても、随時結果を確認できるようになった？ (未確認)

● Flexible scenario output & reports

○ output画面をカスタマイズしやすくするため、グラフを追加ができるような関数ができた

(add_output)

Already improved (Rally task) 3/3 ● Multi API versions support

○ Taskの中でAPI versionをコントロールできるようになりました

○ Libertyのとき、cinder v1のテストが動きませんでしたが、それが動くように

■ まだまだ、対応しきれてない APIもあるようで、課題と認識している

● Heat based VM workloads○ VMTasks.workload_heat

■ Heatでシステムを展開し、そのシステム上で workload(script)を流し、その結果をRallyで収集で

きるというベンチマークシナリオが追加された。

■ 複数台で構成されるシステムの場合、１台 gate_nodeと呼ばれるworkloadを流すVMを指定し、

そこでworkloadを実行するような仕組み

■ 以前より、vmを作成しその上でworkload(script)を流すシナリオはあったが、Heatを使って複数

台構成のシステムに対して workloadを流す仕組みは、Mitakaで初めて実装された

Rally Next Step for Newton

Next step(Common)

● Plugin deprecation name/rename mechanism● Rally as a Library

○ rally.orchestrator.apiというところに実装されている、 rallyの各処理(deploymentの作成、taskの作

成...)をまとめたプログラムを、もっと汎用的にしようという取り組み

■ このLibraryが● Rally as a Serviceのapi部分から利用される (=> Rally as a Serviceの実装をBlock)● Rally as a App(従来のCLI)のcli部分から利用される

● Rally as a Service(結構前から言われている )○ 現状Rallyは、１つのCLIソフトウェアとして動いている

○ RallyをClient Serverモデルで実装するという話

■ 従来のCLIソフトウェアも機能を潰さず、このまま維持メンテしていく

Next step(Rally verify)

● Rally verify generalization○ Rally verify機能をもっと一般化しようという話

■ 今は、Tempestを用いた試験しかできない

■ 各プロジェクトのUnit Test、OSTFなどTempest以外のテストフレームワークを叩けるようにす

る

● Ability to Install Tempest plugins [1]

○ Tempestには、pluginという概念があり、pluginを実装したtestcaseを書き、tempest.confにplugin

名を記入すると tempestから独自の testcaseを実行できる仕組みがある。

○ そのPluginもrallyのcliでインストールできるようにする

● ドキュメントがまだまだ足りないので書こう

Next step(Rally task) 1/3

● New Rally task format [1] (Kiloの時からずっと取り組んでいる取り組み )○ Rallyのtaskファイル(どういうbenchmarkを流すかを定義する file)のformatを変更する取り組み

■ この取り組みが始まってから、現在の task formatに関するパッチ (機能追加)は、入りづらくなっ

てます

● Task validation refactoring● Multi scenario support (blocked by new task format)

○ 複数のシナリオを同時に流せるようにする、現状の task formatでは実現できないので、 task format

の変更が終わるまで、この機能は入らない

● HA testing (blocked by multi scenario support)○ 破壊的なシナリオを用意し、同時に流して HAの動作を確認するという話

○ Multi scenarioの機能を利用するので、その機能が実装されないとこの機能は入らない

● Testing & Monitoring (depends on above)

Next step(Rally task) 2/3● Disaster cleanup

○ Rally実行中に、意図せぬ状態で落ちた場合に、中途半端に作ったリソースをちゃんと消せるようにしよ

うという話 (resource命名規則の統一は、ここに関連 )● Distributed runner [1][2]

○ ベンチマーク実行側の負荷が高くなるから、ベンチマーク実行 agentを作って複数のagentで１つのベン

チマークを実現しようという話

● Heatless based workload framework [1]

○ Heatをつかわずに複数台で構成されるシステム (クラウド上にdeployされた)に対して特定のworkloadを

流せる仕組みを作ろうという話

● Trend & Compare reports (東京Summitより話題に上がる )○ 複数のベンチマーク結果を指定し、比較できるよな reportを出力しようという → すでにMerge

■ CI Gateにも入れて機能追加ごとのbenchmark結果の遷移を可視化したいという野望がある

Next step(Rally task) 3/3● Rally task certification

○ 明確な目的がないユーザにとって、複数のベンチマークセットの中でどれを回すべきなのかがわか

らないという意見がある

○ １つのタスクに、複数のプロジェクトの有益なベンチマークシナリオ /SLAをまとめたもの

○ このタスクが通れば「Rallyのテスト通過済み (rally certificated)」だと主張できるような仕組みを考え

ている

=> upstreamのCIにも入れたいらしい

所感

● Rally Export機能実装されて、結果を JSONでデータ吐けるようになった

○ 実は、jsonで吐く機能はexport機能が話題になる以前の tokyo summitの頃から欲しい欲しいと言っ

ていた[1]

○ いくつかパッチも出していたが、部分的にしか取り込まれず、気づいたら exportの話が出てて、気づ

いたら別のアプローチで json exportできるようになってた！

■ 確かに、exportのアプローチの方がイケてるなと (自分では思いつかなかった ...)● Trendの機能も実装され始め、結果は今後もっと見やすくなりそう

● Deploy後に定常的に、benchmarkを流して結果を見るようなユースケースを考えると、「 Rally as a Service」は、早く機能実装して欲しい

● Liberty以前から取り組んできている機能追加は、 MitakaでもまだWIPで、Livertyリリース後に、話題に上

がった機能は、すでに実装されているような気がする

○ 開発があまり進んでないのかな？

○ レビューアーが足りないとは言ってました

● Multi scenario/HAあたりが実装されたら、真面目に使う価値がありそう