ロードマップの取り扱い¶

利用できる情報¶

OpenStack 環境の要望を把握するために使用できる、いくつかの良い情報源があります。

リリースノートは OpenStack Wiki で管理され、以下で公開されています。

他にもいくつかリソースがあります。

• 現在の開発中の機能、それらの目標マイルストーンの詳細
• まだ開発中ではないものを含む、すべての機能の一覧
• 直近のデザインサミットからの大まかな設定に関する議論 (etherpad)
• レビュー中の個々のコードの変更の一覧

ロードマップへの影響¶

OpenStack は、あなたのアイディア (およびコントリビューション) を本当に歓迎しています。また、実世界のソフトウェアのユーザーからのフィードバックに高い価値をおきます。機能開発を推進するプロセスについて少し理解することにより、参加でき、あなたの要望を追加できるかもしれません。

機能追加リクエストは、通常 Etherpad で始まります。Etherpad は共同編集ツールで、デザインサミットのその機能に関するセッションで議論を整理するのに使われます。続けて、プロジェクトの Launchpad サイトに blueprint が作成され、blueprint を使ってよりきちんとした形で機能が規定されていきます。 この後、blueprint はプロジェクトメンバーによって承認され、開発が始まります。

あなたの機能追加リクエストを新機能として検討してもらうのに一番早い方法は、アイデアを書いた Etherpad を作成し、デザインサミットのセッションを提案することです。デザインサミットが終わっている場合には、blueprint を直接作成することもできます。 Victoria Martínez の blueprint での開発の進め方についてのブログ を是非読んでください。 OpenStack 開発者のインターンの視点で書かれた記事です。

開発されている次のリリースのロードマップは Releases にあります。

将来のリリースで検討されている機能を確認したり、過去に実装された機能を見るには、OpenStack Compute (nova) Blueprints、` OpenStack Identity (keystone) Blueprints <https://blueprints.launchpad.net/keystone>`_ などの既存の Blueprint やリリースノートを見てください。

開発ロードマップに影響を与えるために、直接ブループリントに関わる道以外に、非常に高く評価された別の方法があります。ユーザー調査です。 OpenStack User Survey にあります。基本的に匿名で、お使いの環境の詳細、要望を送ることができます。各サイクルで、ユーザーコミッティーが結果を分析して、報告書を作成します。具体的な情報を TC や PTL に提供することを含みます。

ウォッチの観点¶

OpenStack の中で改善されている領域を注目しつづけたいでしょう。各プロジェクトのロードマップを「ウォッチ」する最善の方法は、今のマイルストーンリリースにおいて取り組むために承認されたブループリントを確認することです。1 年に 2 回開催されている OpenStack サミットの PTL による webinar からも知ることができます。

分散仮想ルーター¶

OpenStack Networking を長く取り巻く不満の 1 つは、L3 コンポーネントの高可用性の不足でした。Juno リリースは、これを解決することを目指した、分散仮想ルーター (DVR) を導入しました。

初期の目安は、ML2 プラグインと Open vSwitch、1 つのフラットな外部ネットワークと VXLAN のテナントネットワークなど、基本的なシナリオに対してこれをうまく実行することです。しかしながら、VLAN、IPv6、Floating IP、大量のノース・サウス通信のシナリオ、大量のコンピュートノードなどで問題が発生しはじめます。これらは次のリリースで大幅に改善されることが期待されていますが、特定の問題におけるバグ報告が強く望まれています。

Modular Layer 2 プラグインによる Open vSwitch プラグインの置換¶

Modular Layer 2 プラグインは、OpenStack Networking が複雑な実世界のデータセンターに見られるさまざまな L2 ネットワーク技術を同時に利用できるようにするフレームワークです。現在、既存の Open vSwitch、Linux Bridge、Hyper-V L2 エージェントと一緒に動作します。それらの L2 エージェントと関連付けられたモノリシックなプラグインを置き換えて廃止することを意図しています。

新しい API¶

Compute API の 3 番目のバージョンが幅広く議論され、Havana と Icehouse のリリースサイクル期間中に取り組まれました。現在の議論は、V2 API が多くのリリースのために残され、次の API の繰り返しは v2.1 と表示されます。これは、完全に新しい v3 API ではなく、既存の v2.0 と同じようなプロパティーを持ちます。これは、すべての API を評価するための良い機会です。次世代の API が定義されるまでにコメントを出します。新しいワーキンググループが特別に形成され、OpenStack API を改善して、設計のガイドラインを作成します。あなたの参加も歓迎されています。

OpenStack on OpenStack (TripleO)¶

このプロジェクトは改善を続けています。greenfield の導入のために使用することを検討する可能性があります。最新のユーザー調査の結果によると、大幅な理解が得られたままです。

OpenStack の Data Processing サービス (sahara)¶

ビッグデータの問題に対する最も要望された回答です。専門チームが Hadoop-as-a-Service プロジェクトに安定した進捗を実現しました。

Bare metal Deployment (ironic)¶

ベアメタル配備は幅広く叫ばれていて、開発が続いています。Juno リリースは、OpenStack Bare metal ドライブを Compute プロジェクトの中に持ち込みました。Kilo において、既存のベアメタルドライバーを目指していました。現在ベアメタルドライバーを使用している場合、従うべき具体的なブループリントは Deprecate the bare metal driver です。

Database as a Service (trove)¶

OpenStack コミュニティーは、何回か開発中の database-as-a-service ツールがありました。Icehouse において最初の統合リリースがありました。そのリリース以降、高可用な方法でそのまま使えるデータベースサーバーを配備できます。最初は MySQL のみをサポートしていました。Juno では、Mongo (クラスターを含む)、PostgreSQL、Couchbase、MySQL の複製機能をサポートしました。Kilo では、さらに高度なクラスター機能が導入されました。また、Networking などの他の OpenStack コンポーネントとより統合されました。

Message サービス (zaqar)¶

メッセージと通知のキューを提供するサービスが提供されました。

DNS サービス (designate)¶

長く要望されていたサービスです。配下を収集した OpenStack リソースを関連付けられた DNS エントリーを操作する機能を提供します。designate プロジェクトもリリースされました。

スケジューラーの改善¶

Compute と Block Storage はどちらも、仮想マシンやボリュームを配置する場所を決めるためにスケジューラーに頼っています。Havana では、Compute のスケジューラーが大幅に改善されました。これは、Icehouse において支援を受けた Block Storage におけるスケジューラーでした。さらに掘り下げて追跡すると、どちらも取り扱う全体的なスケジューラーを作成することを目指した、このサイクルを始めた努力が実を結ぶでしょう。Kilo において実行されたいくつかの作業は、Gantt project にあります。