[ English | Indonesia | Deutsch | 日本語 ]
ロードマップの取り扱い¶
良いお知らせ: OpenStack は、次に行われることに関する情報を提供する際に、前例がないくらいにオープンです。悪いお知らせ: 各リリースが非常に迅速に行われます。この付録の目的は、参照しておく価値のあるページをいくつか紹介すること、次のリリースやその先に起こることを根拠を持って推測することです。
OpenStack は6ヶ月のリリースサイクルを取っており、通常は4/5月と10/11月にリリースが行われます。各リリースサイクルの最初に、OpenStack コミュニティは一ヶ所に集まり Project Team Gathering (PTG) を行います。 PTG では、次のリリースでの機能が議論され、優先度付けと計画が行われます。以下の図は、リリースサイクルの一例で、サミットが行われて以降のマイルストーンリリース、Code Freeze、String Freeze などが記載されています。マイルストーンはリリースサイクル内での中間リリースで、テスト用にパッケージが作成され、ダウンロードできるようになります。 Code Freeze では、そのリリースに向けての新機能の追加が凍結されます。String Freeze は、ソースコード内の文字列の変更が凍結されることを意味します。
利用できる情報¶
OpenStack 環境の要望を把握するために使用できる、いくつかの良い情報源があります。
`OpenStackのリリースバージョンとリリースノートの一覧<https://releases.openstack.org/>`_ こちらより新機能、更新された機能、非推奨の機能、バージョン間の非互換を確認してください。
ロードマップへの影響¶
OpenStack は、あなたのアイディア (およびコントリビューション) を本当に歓迎しています。また、実世界のソフトウェアのユーザーからのフィードバックに高い価値をおきます。機能開発を推進するプロセスについて少し理解することにより、参加でき、あなたの要望を追加できるかもしれません。
機能追加リクエストは、通常 Etherpad で始まります。Etherpad は共同編集ツールで、デザインサミットのその機能に関するセッションで議論を整理するのに使われます。続けて、プロジェクトの Launchpad サイトに blueprint が作成され、blueprint を使ってよりきちんとした形で機能が規定されていきます。 この後、blueprint はプロジェクトメンバーによって承認され、開発が始まります。
あなたの機能追加リクエストを新機能として検討してもらうのに一番早い方法は、アイデアを書いた Etherpad を作成し、PTG のセッションを提案することです。 PTG が終わっている場合には、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 からも知ることができます。
ドライバー品質の改善¶
主要な品質は、Block Storage、Compute、Networking におけるドライバーやプラグインをまたがり発生しています。とくに、プロプライエタリーやハードウェア製品を必要とする Compute と Networking のドライバー開発者は、開発プロセス中に使用するために、自動化された外部テストシステムを提供する必要があります。
より簡単なアップグレード¶
より簡単なアップグレードは、OpenStack の開始以来、もっとも要望されている機能の 1 つです。Object Storage 以外のコンポーネントは「作業中」です。最近のリリースでは、内部メッセージ通信がバージョン付けされています。サービスが理論的には後方互換性の動作まで戻れることを目的としています。これにより、古いバージョンをいくつか残しながら、いくつかのコンポーネントの新しいバージョンを実行できるようになります。
さらに、データベースの移行が Turbo Hipster ツールを用いてテストされます。このツールは、実世界のユーザーのデータベースのコピーにおいて、データベースの移行パフォーマンスをテストします。
これらの変更は、 アップグレード にある OpenStack アップグレードガイドを促進しました。次のリリースにおいて継続的に改善されつづけています。
nova-network の非推奨¶
Folsom リリースにおいて OpenStack Networking (neutron) により提供された完全な SDN スタックの導入により、Compute のコンポーネントの一部に残っている、初期のネットワークのコードにおける開発の努力が徐々に少なくなってきました。まだたくさん本番環境で nova-network を使用していますが、より柔軟で完全な機能を持つ OpenStack Networking に移行して、そのコードを削除する長期的な計画がありました。
Havana リリース中に nova-network を廃止しようという試みがありました。これは、このガイドで言及した FlatDHCP マルチホスト高可用性モードなどの同等機能の不足、バージョン間の移行パスの不足、不十分なテスト、伝統的にサポートされる nova-network のより簡単なユースケースに使用する場合のシンプルさ、などの理由により中断されました。甚大な努力によりこれらの心配事を解決してきましたが、 nova-network は Juno リリースにおいて廃止されませんでした。さらに、Juno においてネットワークごとの設定機能や SR-IOV の追加などの限定された範囲で、 nova-network へのパッチが再び受け入れられてきました。
これは、クラウドを設計するときに、重要な判断ポイントを残します。OpenStack Networking は、いくつかのシナリオにおける性能問題、L3 システムの基本的な高可用性のみなど、少しの制限を持ちますが、十分使用できる堅牢さを持ちます。 nova-network よりも多くの機能を提供します。しかしながら、より完全な SDN の機能から利益を得る、より複雑なユースケースを持たない場合、または新しく導入された概念になじめない場合、 nova-network は次の 12 か月間の主要な選択肢であり続けるかもしれません。
同様に、既存のクラウドを持ち、 nova-network から OpenStack Networking にアップグレードするつもりである場合、この期間中のアップグレードを遅らせる選択肢もあるでしょう。しかしながら、OpenStack の各リリースは新しい重要なイノベーションをもたらします。ネットワークの使用法によらず、各リリースの合理的な時間枠の中でアップグレードの計画を始めることが最も良いでしょう。
言及されたとおり、 nova-network から neutron にきれいに移行する方法は現在ありません。適切な移行パスがリリースされるまで、移行を心に留めておき、そのプロセスに関わることを推奨します。
分散仮想ルーター¶
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 の導入のために使用することを検討する可能性があります。最新のユーザー調査の結果によると、大幅な理解が得られたままです。
Data processing service for OpenStack (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 Service (zaqar)¶
メッセージと通知のキューを提供するサービスが提供されました。
DNS service (designate)¶
長く要望されていたサービスです。配下を収集した OpenStack リソースを関連付けられた DNS エントリーを操作する機能を提供します。designate プロジェクトもリリースされました。
スケジューラーの改善¶
Compute と Block Storage はどちらも、仮想マシンやボリュームを配置する場所を決めるためにスケジューラーに頼っています。Havana では、Compute のスケジューラーが大幅に改善されました。これは、Icehouse において支援を受けた Block Storage におけるスケジューラーでした。さらに掘り下げて追跡すると、どちらも取り扱う全体的なスケジューラーを作成することを目指した、このサイクルを始めた努力が実を結ぶでしょう。Kilo において実行されたいくつかの作業は、Gantt project にあります。
Block Storage の改善¶
Block Storage は、品質ドライバーの幅広い理解と長く取られている記録を持つ、安定したプロジェクトと考えられています。このチームは、よりよいエラー報告、自動探索、シンプロビジョニング機能など、さまざまな領域の作業をサミットで議論しました。
Python SDK へ¶
OpenStack と通信するための効率的な SDK として、さまざまな python-*client コードを使用してとても成功していますが、プロジェクト間の整合性とドキュメントの入手可能性は満ち欠けがあります。これを取り除くために、エクスペリエンスを改善するための取り組み が開始されました。OpenStack におけるクロスプロジェクトの取り組みは、いくつかの失敗から始まった 統一クライアントのプロジェクト など、波乱の歴史があります。しかしながら、SDK プロジェクトの初期の目安が約束され、Juno サイクル中に結果を見ることを期待しています。
