OpenStack Summit AustinのDesign Summitで実施された、 「RallyのMitakaでのUpdatesとNewtonの開発項目」のセッションのまとめ資料です。 本資料は、セッションで使われた資料を掻い摘んで日本語の注釈/私なりの解釈を追加しています。(元資料はこちら: https://docs.google.com/presentation/d/1g5fd2BJXc40yienjCB0Fuc8NaB0e5pQO0XbUHQ1CY0s )

1. OpenStack Rally
Mitaka Updates ＆ Next-step for Newton
OpenStack Summit Austin報告 (1/2)
Yuki Nishiwaki

2. About my material
PTLであるMr. Borisが「Overview of Mitaka results and Newton Goals」というセッションで喋って
いたときの資料を貰い、その資料を掻い摘みつつ、日本語の注釈を交えながらスライド
を作成しています。
セッションで実際に使われた資料はこちら:
https://docs.google.com/presentation/d/1g5fd2BJXc40yienjCB0Fuc8NaB0e5pQO0XbUHQ1CY0s

3. 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に入り始めて注目度が上がってる？

4. 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より引用

5. 今は１つのプロセスで全て動いている
(実行時に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を実行
できるように
Distributed
Benchmark runner
Distributed
Benchmark runner
Distributed
Benchmark runner
Now developing

6. Rally Mitaka Updated

7. 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が追加

8. 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を取り込めるようになりました

9. Xfail mechanism
● 失敗するテストを下記のように指定:
{“test.full.name”: “reason”}
● rally verify start --xfail-fail <that_fail>
● 失敗しても、成功と認識される

10. 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の命名規則

11. 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)

12. 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で初めて実装された

13. Rally Next Step for Newton

14. 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ソフトウェアも機能を潰さず、このまま維持メンテしていく

15. 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でインストールできるようにする
● ドキュメントがまだまだ足りないので書こう

16. 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)

17. 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結果の遷移を可視化したい という野望がある

18. Next step(Rally task) 3/3
● Rally task certification
○ 明確な目的がないユーザにとって、複数のベンチマークセットの中でどれを回すべきなのかがわか
らないという意見がある
○ １つのタスクに、複数のプロジェクトの有益なベンチマークシナリオ /SLAをまとめたもの
○ このタスクが通れば「 Rallyのテスト通過済み(rally certificated)」だと主張できるような仕組みを考え
ている
=> upstreamのCIにも入れたいらしい

19. 所感
● 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あたりが実装されたら、真面目に使う価値がありそう