Jump to: navigation, search

ReleaseNotes/Kilo

Revision as of 05:23, 6 May 2015 by Amotoki (talk | contribs)
Other languages:
English • ‎日本語 • ‎한국어 • ‎русский • ‎中文(简体)‎ • ‎中文(台灣)‎

OpenStack 2015.1.0 (Kilo) リリースノート

先日他界した Chris Yeoh 氏に OpenStack Kilo リリースを捧げます。彼はあまりにも早くご家族と私達の元を去ってしまいました。

Contents


OpenStack Object Storage (Swift)

主要な新機能

Erasure Code(イレイジャーコード:消失訂正符号) (ベータ版)

Swift は本バージョンでErasure Code (イレイジャーコード:消失訂正符号、以下EC) タイプのストレージポリシーをサポートしました。この機能により、構築者はストレージのレプリケーションで使用する物理容量よりも少ない容量で非常に高い堅牢性を実現できます。しかし、EC はレプリケーションより多くのCPU とネットワークリソースを必要とするため、すべてのユースケースに適合するものではありません。EC は大容量で頻繁にアクセスされないデータを 1 つのリージョンで保存するのに適しています。

SwiftのECはエンドユーザーに対して透過的になるように実装されています。レプリケーションとECにはAPIの差異はありません。

Swift の EC は PyECLib および liberasurecode に依存しています。liberasurecode は、実際の EC アルゴリズムをお使いのライブラリーに実装可能にするプラグ可能なライブラリーです。

完全なドキュメントは http://swift.openstack.org/overview_erasure_code.html にあります。

合成トークン (Composite token)

合成トークンはSwift以外のOpenStackサービスがクライアントの代わりにSwiftにデータを保存できるようにするための機能です。これによりクライアントとサービスを合わせることなくデータをアップデートできます。

例としては、ユーザーがNovaがVMのスナップショットを保存するように要求する場合があります。NovaはGlanceに要求を行い、GlanceはイメージをSwiftのコンテナーにオブジェクトの集合として書き込みます。この際、ユーザーは、Novaサービスの有効なトークンがない限り、そのスナップショットを変更できません。また、Nova サービスも、有効なユーザートークンなしにそのデータを変更することはできません。ただし、データ自体はユーザーのアカウント配下に保存されます。これは、使用量の管理をシンプルにするためです。

詳細なドキュメントは http://swift.openstack.org/overview_backing_store.html にあります。

小さく不均一なクラスターでのデータ配置変更

Swiftのデータ配置はデバイスの重みから計算されるようになりました。この機能により、一気に大量のデータを移動させずに、徐々に新しいゾーンやリージョンを増やすことができるようになります。また、もしクラスターが不均一だった場合(例えば、クラスターにゾーンが2つ存在するが、片方のゾーンがもう一方の2倍の容量だった場合など)、Swiftはクラスターが「十分に均一ではない」と警告を出し、利用可能な領域をより効率的に使うようになりました。

グローバルクラスターのレプリケーション改善

リージョン間でのレプリケーションにおいて、1回のレプリケーション実行で移動されるレプリカが1つだけになりました。これにより、リモートのリージョン内でレプリケーションが行われることを期待でき、WAN越しのデータ移動を削減することができます。

既知の問題

  • ECのサポートはベータリリースであり、近い将来すべての機能がそろいますが、現在は(マルチレンジの読み込みなど)いくつかの機能はサポートされておらず、性能特性の確認も完了していません。この機能は堅牢性の確保をssyncに依存しています。構築者はECストレージポリシーを使う際には、十分にテストを行い、プロダクションデータを保存しないことを強く推奨します。

アップグレード時の注意

これまで通り、エンドユーザーへのダウンタイムなしで、Swift をアップグレードできます。

  • ECをサポートするために、SwiftはPyECLib(及び必然的にliberasurecode)に依存することになります。また、eventlet の最小バージョンが引き上げられました。


OpenStack Compute (Nova)

主要な新機能

API v2.1

  • Kilo では、デフォルトで v2.0 API リクエストの処理は引き続き v2.0 API コードを使用しています。Liberty では、v2.0、v2.1 両方のリクエスト処理に v2.1 API コードを使用したいと考えています。
  • Liberty に向け、v2.0 API は今回凍結され、今後新機能は全て、マイクロバージョンを使って v2.1 API に追加される事になりました。Kilo で増加したマイクロバージョンは以下の通り。
    • (Windows WinRM で使用される)x509 認証対応用キーペア API 拡張。これは、v2.1 API のマイクロバージョンに追加された最初の API 機能です。
    • os-extended-server-attributes の追加属性の公開。
  • python-novaclient はまだ v2.1 API をサポートしていません
  • Nova v2.1 API のポリシー制御が改善されました。
    • ポリシーは API の入り口でのみ制御されます。
    • 単一 API に複数ルールの適用が出来なくなりました。
    • v2 API と区別する為に、v2.1 API ポリシールールは全てプレフィックスとして「os_compute_api」を使用します。
    • DBレイヤーでハードコーディングされた権限チェックのせいで、従来 Nova API の一部はポリシーで設定する事が出来ず、これらは常に管理者権限を必要としていました。Nova v2.1 の一部のハードコーディングされた権限チェックは削除され、API のポリシー設定が可能になりました。残りの部分のハードコーディングされた権限チェックは Liberty で削除される予定です。

アップグレードのサポート

  • DB マイグレーションスクリプト中で起こるデータのマイグレーションを削減しました。これは現在、DB のオブジェクトコードにおける「後回しな」方法で処理されます。nova-manage コマンドにはデータのマイグレーション強制実行を手助けする為のコマンドがあります。詳細は次を参照して下さい:http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/flavor-from-sysmeta-to-blob.html
  • https://review.openstack.org/#/c/97946/ の変更は、データベースマイグレーション 267 を追加します。これは、instances.uuid が NULL のレコードをスキャンし、該当するレコードが発見された場合は失敗します。理由は、マイグレーションが最終的に instances.uuid カラムを NULL 禁止に変更する必要があり、Unique 制約を付加するからです。データベースマイグレーション実行前に instances.uuid が NULL のレコードを検索するヘルパースクリプトが提供されています。「nova-manage db sync」実行前に、ヘルパースクリプト「nova-manage db null_instance_uuid_scan」を実行して下さい。これは、(デフォルトで)単にレコードを検索して結果をダンプするだけで、何も変更しません。null_instance_uuid_scan コマンドに --delete オプションをつけると、instances.uuid が NULL のレコードを自動的に削除します。

スケジューラー

  • パフォーマンス向上セクション
  • スケジューリング機能の発展・改善を可能にするスケジューラー構造の変更が進行しています。この変更はエンドユーザーからは見えないはずです。

Cells v2

  • Cells v2 対応の最初のいくつかの部分が追加されましたが、この機能はまだ使用できる状態ではありません。
  • Cells 用の新しい API データベースで機能する新しい「nova-manage api_db sync」と「nova-manage api_db version」コマンドがありますが、このデータベースはまだ使われていないので、セットアップする必要はありません。

Compute ドライバー

Hyper-V
Libvirt (KVM)
VMware
Ironic

既知の問題

  • Evacuate のリカバリコードは(VM のディスク)データを破壊する可能性があります。nova-compute 起動時、ハイパーバイザが報告したインスタンスが障害発生中に現在のホストから別ホストに移動したか(つまり、evacuate されたか)チェックされます。もし移動された VM があると判断された場合、それらの VM は現在のホスト上から削除されます。これは、移動済みインスタンスが間違って選択され、予期せずインスタンスが削除される可能性があります。libvirt 系ノードでは、これは OS ホスト名の変更によって引き起こされます。VMware 系ノードでは、1つの vCenter 環境を(異なるホスト名を持つ)2つの異なるホストから管理しようとする際に引き起こされます。これらは Liberty で適切に修正される予定ですが、現時点では、予防措置として workarounds.destroy_after_evacuate=False を設定する事でこの挙動を無効化する事ができます。【注意】これはリグレッションではなく、evacuate 機能が実装された時からの設計上の欠陥です。この問題の修正は容易ではありません。それゆえ、この迂回策はダメージの可能性を制限するものです。Liberty で提案された修正はこちら: https://review.openstack.org/#/c/161444/.
  • サンプル設定ファイルの生成では、oslo 関連の設定が欠ける可能性があります。

アップグレード時の注意

下記はアップグレード時に知っておくべき事です。git commit ハッシュがある所は、それが詳細情報を見つける手助けになるでしょう:

  • Nova の外側で作成された場合、Neutron のポートはサーバ削除後に自動的に削除されないようになりました: 1153a46738fc3ffff98a1df9d94b5a55fdd58777
  • 削除予定だった EC2 API は、Kilo で削除されそうです: f098398a836e3671c49bb884b4a1a1988053f4b2
  • Web ソケットプロキシーは API ノードでの手順を踏んだアップグレードが必要です(古い API ノードはコンソールアクセス認証時に access_url を送付せず、新しいプロキシーサービスはこれらの認証に失敗するため): 9621ccaf05900009d67cdadeb1aac27368114a61
  • Kilo に完全にアップグレードした(つまり、全ノードが Kilo コードで動いている)後、フレーバー情報を古い場所から新しい場所にバックグラウンドでマイグレーションする作業を開始すべきです。Kilo の conductor ノードはこの作業を必要に応じて稼働中に行いますが、残りの未使用データはバックグラウンドでマイグレーションする必要があります。古い場所のサポートは Liberty で削除される予定なので、このマイグレーション作業は Liberty リリースの前に必ず済ませておかなければなりません。「nova-manage migrate-flavor-data」を使用して、この変換を実行して下さい。
  • Nova v2.1 API ポリシー強制の実装により、v2.1 API ポリシーには多数の変更が発生しました。v2.1 API はこれまでリリースされていないので、これらの変更は後方互換性を維持しません。古いポリシーを使用するより、サンプルのポリシー設定を使用した方が良いでしょう。
  • VMware のレスキュー VM 動作は新しい VM を作らなくなり、代わりに同一 VM 中で行われます: cd1765459a24e52e1b933c8e05517fed75ac9d41
  • 廃止予定だった「force_config_drive = always」の代わりに「force_config_drive = True」を使って下さい: c12a78b35dc910fa97df888960ef2b9a64557254
  • Hyper-V を使っていて、コミット b4d57ab65836460d0d9cb8889ec2e6c3986c0a9b 〜 c8e9f8e71de64273f10498c5ad959634bfe79975 の間のコードを使用している場合、手動で修正すべき問題があります。参考: c8e9f8e71de64273f10498c5ad959634bfe79975
  • 「multi_instance_display_name_template」のデフォルト値の変更。参考: 609b2df339785bff9e30a9d67d5c853562ae3344
  • DB マイグレーションがきれいに適用されることを確認するため、「nova-manage db null_instance_uuid_scan」を実行して下さい。参考: c0ea53ce353684b48303fc59393930c3fa5ade58


OpenStack Image Service (Glance)

主要な新機能

既知の問題

アップグレード時の注意

  • 廃止予定だったオプション db_enforce_mysql_charset を削除しました。関連コミット: efeb69f9033a57a1c806f71ee3ed9fd3f4d2475e
  • metadef リソースの通知に対応しました。関連コミット: fd547e3717dc4a3a92c1cb2104c18608a4f4872a
  • 2,3 の設定変更で VMware 複数データストアを有効に出来ます。関連コミット: 96fb31d7459bd4e05e052053177dce4d38cdaf90
  • 非同期処理用の eventlet 実行コードを削除し、新しい taskflow 実行コードを追加しました。関連コミット: ae3135e1d67df77697a24fddaee3efeadb34a0dd、 a39debfd55f6872e5f4f955b75728c936d1cee4b
  • snet 設定をエンドポイント設定で置き換えました。関連コミット: 41a9a065531ec946b4a9baf999f97d10fa493826
  • ダイジェストアルゴリズムが設定可能になりました。関連コミット: 82194e0c422966422f7a4e2157125c7ad8fbc5b5
  • イメージ削除時、「saving」状態だった削除イメージのゴミを掃除します。関連コミット: 0dc8fbb3479a53c5bba8475d14f4c7206904c5ea
  • Glance は卒業した oslo.policy を使用するようになりました。関連コミット: cb7d5a4795bbdaf4dc3eaaf0a6fb1add52c09011
  • イメージを無効化できるようになりました。「deactivated」という新しい状態がイメージデータアセットに追加されました。関連コミット: b000c85b7fabbe944b4df3ab57ff73883328f40d


OpenStack Dashboard (Horizon)

主要な新機能

  • Webシングルサインオン経由での認証連携に対応…keystone で設定した場合、ユーザーは OpenStack 環境が対応している認証機構から1つを選択できるようになります。この機能を使うためには、local_settings.py を変更して機能を有効にしなければなりません。この機能に関連する設定はこちらにあります。
  • テーマに対応…Horizon でカスタマイズテーマを指定する、より簡単な機構が追加されました。カスタム CSS をインクルードするだけでなく、Bootstrap の CSS 値と Horizon 変数の使用もできます。詳細はこちらを参照して下さい。
  • Sahara ユーザーインターフェースの改善…追加のガイド付きクラスター作成とガイド付きジョブ作成ページにより、Sahara のユーザーインターフェースの利便性が劇的に改善しました。
  • インスタンス作成ウィザード (ベータ版)…既存のインスタンス作成ワークフローにおける利便性の問題を解決する為、インスタンス作成ワークフローが AngularJS で完全に再実装されました。導入の遅れと限定的なテストの為、この機能は Kilo ではベータ版とされ、デフォルトでは有効になっていません。新しいワークフローを使用するためには、local_settings.py における以下の変更が必要です: LAUNCH_INSTANCE_NG_ENABLED = True 加えて、以下の設定でデフォルトのインスタンス作成ウィザードを無効化します: LAUNCH_INSTANCE_LEGACY_ENABLED = False この新機能は、Horizon の開発の将来像となるでしょう。
  • Nova
    • ハイパーバイザー上のサービスの有効・無効化に対応
    • ホストから全インスタンスをマイグレーション
    • シリアルコンソールの公開
  • Cinder
    • Cinder v2 API がデフォルトに
    • 管理/非管理ボリューム対応…管理者が cinder の管理対象外の既存のボリュームを cinder の管理対象にしたり、逆に管理対象外にしたりできます。
    • プロジェクト間のボリュームの譲渡に対応
    • ボリューム暗号化メタデータに対応
  • Glance
    • 管理者によるGlanceメタデータ定義の確認/追加/変更
  • Heat
    • スタックテンプレート一覧
    • オーケストレーションリソースパネル
    • スタックのサスペンド/リジュームアクション
    • スタック作成前に指定されたスタックのプレビュー
  • Trove
    • Trove インスタンスのリサイズ -- インスタンスのフレーバーの変更
  • Ceilometer
    • CeilometerからのIPMIメータ値を表示
  • Horizon における新しい再利用可能な AngularJS ウィジェット:
    • AngularJS でのテーブルの実装
      • テーブル描画機能…拡張可能なテーブルコンテンツ
      • 改善されたクライアント側/サーバー側での検索
    • テーブルウィジェットの転送
  • Horizon のトップ階層を「/」以外に変更可能に

既知の問題

アップグレード時の注意

  • Django 1.7 がサポートされています。


OpenStack Identity (Keystone)

主要な新機能

階層的なプロジェクト管理

新しいプロジェクトを作成する際、既に存在するプロジェクトを parent_id 属性に指定して、他のプロジェクト配下にすることができます。また、既存のプロジェクトに対して、get-projectAPI/v3/projects により、その親子関係を取得することができます。

Role は、階層的なプロジェクトツリー上で、usersgroups の両方に紐付けすることができます。

この機能がもっと有用なものとなるには、他のOpenStackサービスによるサポートが必要です(例えば階層的なクォータ等)。

Fernet トークン

UUID トークンがデータベースに保存して永続化しておく必要があるのに対し、Fernet トークンは完全に非永続的なものです。構築者は keystone.conf 中の [token] provider = keystone.token.providers.fernet.Provider を使って Fernet トークンプロバイダーを有効にできます。

Fernet トークンは対象暗号鍵が必要で、暗号鍵はkeystone-manage fernet_setupで作成し、keystone-manage fernet_rotate を使って鍵を定期的にローテーションしなければなりません。これらの鍵はマルチノード環境(またはマルチリージョン環境)では全ての Keystone ノードで共有し、あるノードで作成されたトークンが即座に他ノードでも検証できるようにする必要があります。

認証連携 (Identity Federation)

  • Keystone は他の Keystone インスタンスにローカルユーザーの SAML アサーションを発行することで、連携アイデンティティープロバイダー (IdP)として振る舞う事ができるようになりました(ECP でラップ可能)。
  • 連携アイデンティティー認証機構として、OpenID 接続に対応しました。
  • Keystone において、単一のアイデンティティープロバイダーを多くの「リモートID」に紐付け可能になりました。これは、多くのアイデンティティープロバイダーが共通マッピングを使用している場合に有用です。
  • シングルサインオンページを経由して、既存の IdP に Web ブラウザ経由でユーザー認証する機能を追加しました。
  • 連携トークンが token 認証方式を使用できるようになりました。 mappedsaml2も引き続き利用可能です。
  • 連携ユーザーがローカルの既存アイデンティティーにマッピングできるようになりました。
  • マッピングのルールセットで指定されるグループが名前とドメインで指定可能になりました。
  • 連携認証アサーションで示されるグループが、ローカルのメンバーマッピング込みで自動的に既存のローカルグループにマッピングされるようになりました(ホワイトリスト/ブラックリストでフィルタリング可能)。

LDAP

  • API ユーザーにより指定されたフィルターパラメーターが、Keystone ではなく LDAP 自身で処理されるようになりました。
  • HTTP API を使用して、ドメイン固有のアイデンティティーバックエンドの設定を SQL DB 上で保存できるようになりました(実験段階)。 この機能の最初の使用法は、Keystone の再起動不要の HTTP API による新しいドメインの作成と、その後すぐドメイン固有の LDAP ドライバ設定です。

認可

  • 「assignment」バックエンドが、(ドメイン、プロジェクト、ロールなどの)「resource」バックエンドと、権限マッピングモデルが定義する「assignment」バックエンドに分割されました。
  • 権限の再委託(trust redelegation)に対応しました。委託が最初に作成される際に再委託が許可されていれば、委託先は別の委託先に対して再度委託することができます。
  • ユーザーが default_project_id 属性セットを持っていたとしても、Keystone からスコープ外のトークンを明白に要求することができるようになりました。
  • システム構築者が keystone.conf 中で [token] allow_rescope_scoped_token = false を設定することで、スコープ中のトークンの再スコープを許可しないようにすることができるようになりました。


アップグレード時の注意

  • Keystone の XML 対応は Kilo で削除されました。Keystone Paste 設定から XML と XmlBodyMiddleware の参照を削除することを推奨します。XML ミドルウェアフィルターの削除と、XML フィルターを参照している public_api、admin_api、api_v3、public_version_api、admin_version_api などのパイプラインからの削除が必要です。
  • 以前の拡張機能(OS-FEDERATION, OS-OAUTH1, OS-ENDPOINT-POLICY and OS-EP-FILTER)は全てデフォルトで有効になり、実装レベルに応じて「実験的(experimental)」又は「安定(stable)」と表記されるようになりました。
  • SQL スキーマのダウングレードはサポートされなくなりました。この変更は、SQL マイグレーションのダウングレードが十分にテストされておらず、マイグレーションの多くで発生するデータ変更の量に対応するのがだんだん困難になってきているとの評価結果によるものです。
  • 次の Python ライブラリが必要です: cryptography, msgpack-python, pysaml2, oauthlib.
  • oslo_middleware.sizelimit.RequestBodySizeLimiter 採用により、keystone.middleware.RequestBodySizeLimiter が廃止予定となり、Liberty で削除される予定です。
  • public_bind_host, bind_host, admin_bind_host, admin_port, public_port, public_workers, admin_workers, tcp_keepalive, tcp_keepidle 等の Eventlet 固有のオプションが [DEFAULT] 設定セクションから新しい [eventlet_server] 設定セクションに移動されました。同様に、enable, certfile, keyfile, ca_certs, cert_required 等の Eventlet 固有の SSL 設定オプションが [ssl] 設定セクションから新しい [eventlet_server_ssl] 設定セクションに移動されました。
  • keystone.token.persistence.backends.sql 採用により、keystone.token.backends.sql は削除されました。
  • keystone.token.persistence.backends.kvs 採用により、keystone.token.backends.kvs は削除されました。
  • keystone.token.persistence.backends.memcache 採用により、keystone.token.backends.memcache は削除されました。
  • keystone.assignment.backends.sql 採用により、keystone.assignment.backends.kvs は削除されました。
  • keystone.identity.backends.sql 採用により、keystone.identity.backends.kvs は削除されました。
  • 外部ツールの採用により、keystone.contrib.stats.core.StatsMiddleware は削除されました。
  • keystone.catalog.backends.templated.Catalog の採用により、keystone.catalog.backends.templated.TemplatedCatalog は削除されました。
  • 外部アクセスログの採用により、keystone.contrib.access.core.AccessLogMiddleware は削除されました。
  • keystone.trust.backends.sql 採用により、keystone.trust.backends.kvs は削除されました。
  • 関連するセキュリティ強化の取り組みの一環として、keystone.conf から [catalog] endpoint_substitution_whitelist は削除されました。
  • [token] provider 採用により、keystone.conf から [signing] token_format は削除されました。

OpenStack Network Service (Neutron)

主要な新機能

  • DVR は VXLAN/GRE に加えて、VLAN に対応しました。
  • ML2 階層的ポートバインディング
  • 新しい LBaaS バージョン 2 API
  • OVS ML2 ドライバーにおけるポートセキュリティ機能への対応
  • Kilo で新しく対応したプラグインは以下の通り
    • A10 Networks LBaaS V2 ドライバー
    • Brocade LBaaS V2 ドライバー
    • Brocade ML2 ドライバー(MLX、ICX スイッチ用)
    • Brocade L3 ルーティングプラグイン (MLX スイッチ用)
    • Brocade Vyatta vRouter L3 プラグイン
    • Brocade Vyatta vRouter Firewall ドライバー
    • Brocade Vyatta vRouter VPN ドライバー
    • Cisco CSR VPNaaS ドライバー
    • Dragonflow SDN ベースの分散仮想ルーター L3 プラグイン
    • Freescale FWaaS ドライバー
    • Intel Mcafee NGFW FWaaS ドライバー
    • IPSEC Strongswan VPNaaS ドライバー

既知の問題

  • Firewall-as-a-Service (FWaaS) は Kilo リリースでも依然として実験的な機能です。
  • バグ 1438819
    • 新しいサブネットを外部ネットワーク上に作成した場合、その外部ネットワークにゲートウェイを持つ既存の全ルーターは新サブネットから割り当てられた新しいアドレスを使用します。IPv4 ネットワークでは、この問題によりそのサブネット全体がルーターのゲートウェイポートで使い切られてしまう可能性があります。

アップグレード時の注意

Havana 以降、Neutron は明示的なリースデータベースに対応していません ( https://bugs.launchpad.net/bugs/1202392 )。この変更により、未使用の環境変数などの未使用コードが残っていました。この未使用コードを削除するため ( https://review.openstack.org/#/c/152398/ )、dhcp.filter に変更が必要です。

dnsmasq: EnvFilter, dnsmasq, root, NEUTRON_NETWORK_ID=

の行を以下に置き換えてください。

dnsmasq: CommandFilter, dnsmasq, root

アドバンスドサービスが別パッケージに分離され、サービス毎の設定ファイルが使用されるようになったため (具体的にはetc/neutron/neutron_lbaas.conf, etc/neutron/neutron_fwaas.conf, etc/neutron/neutron_vpnaas.conf)、アップグレード後には有効なサービスプロバイダ設定が変わってしまう可能性があります。特に、ロードバランサーとVPNのデフォルトプロバイダー (それぞれ haproxy と openswan) が元々 neutron.conf 中で無効化されていた場合でもアップグレード後はデフォルトで有効になることがあります。アップグレード後に設定を確認し、サービスプロバイダが意図通りに反映されていることを確認して下さい。

【注意】neutron.conf 中で関連するサービスプラグインがロードされていない場合には影響はありません。


  • api_workers のデフォルト値は今回、ホストの CPU 数に一致するようになりました。もしデフォルト値を使用している場合、api_workers があなたの環境に適した数字になっているか確認して下さい。 (https://review.openstack.org/#/c/140493/)
  • neutron.allow_duplicate_networks 設定オプションは Kilo で廃止予定となり、Liberty で削除される予定です。これに伴い、デフォルトの動作で、Neutron の同一ネットワークへの1 VM の複数ポート接続を許可するようになります。 (https://review.openstack.org/163581)
  • LinuxBridge エージェントはデフォルトで VXLAN を有効にするようになりました。 (https://review.openstack.org/160826)
  • neutron-ns-metadata-proxy は root 以外のユーザーで実行可能になりました。 (https://review.openstack.org/147437)

その他(廃止予定/廃止等)

  • 廃止予定
    • Brocade VDX/VCS シリーズハードウェアスイッチ用の Brocade 一体型プラグイン (monolithic plugin) は Liberty で廃止予定になります。このプラグインで提供される機能は、VDX シリーズのハードウェアで利用可能な ML2 ドライバーで提供されます。このプラグインは Liberty リリースサイクル後に削除される予定です。
    • Nexus1000V 用の Cisco 一体型メタプラグインは Liberty リリースで廃止予定になります。このプラグインが提供する機能は、Cisco Nexus1000V ML2 メカニカルドライバーで利用可能です。この一体型プラグインは Liberty リリースサイクル後に削除される予定です。

OpenStack Block Storage (Cinder)

主要な新機能

  • 今回から、新規のデータベーススキーマのアップグレード時に、すぐに Cinder サービスを再起動する必要がなくなりました。サービスはスキーマのアップグレードと独立するようになりました。これは、Cinder のローリングアップグレード対応の一環です!
  • 既存の一貫性グループへのボリューム追加/削除が可能になりました。詳細はこちら
  • 既存の一貫性グループのスナップショットから新しい一貫性グループを作成できるようになりました。詳細はこちら
  • スケジューラーがボリュームバックエンドをどのように選択するかを、より極め細かく調整できるフィルタ/ウェイトを作成できるようになりました。詳細はこちら
  • Cinder バックアップサービスを使用した、暗号化ボリュームのバックアップができるようになりました。詳細はこちら
  • プライベートのボリュームタイプを作成できるようになりました。これは、特定テナントのみで使用可能なボリュームタイプを作る場合や、新しいボリュームタイプをクラウドで利用可能にする前のテスト用途に最適です。「cinder type-create <name> --is-public」を使用して作成します。
  • シンプロビジョニングによるオーバーコミットが設定可能になりました。詳細はこちら
  • ボリュームタイプの説明を追加できるようになりました。「cinder type-create <name> <description>」を使用して設定できます。
  • Cinder は複数の iSCSI パス情報を返すことができるようになりました。これにより、iSCSI コネクタ(クライアント側)は1番目のパスがダウンしている場合でもボリュームにアタッチできます。(コネクタのマルチパス機能が有効な場合無効の場合)

アップグレード時の注意

  • redis の場所を指定する「host」との名前衝突を避ける為、cinder.conf 中の複数バックエンドにおける「host」設定オプション名は「backend_host」に変更されました。このオプションを使用する場合、設定ファイルが更新されている事を確認して下さい。


OpenStack Telemetry (Ceilometer)

主要な新機能

  • ポーリングプログラム(pollsters)がサービス API に同時に問い合わせないようにする為、ポーリング間隔に jitter を追加しました。
  • Ceilometer API RBAC 対応
  • Event 対応の改善:
    • イベントの単一処理・発行を有効にする、複数パイプラインに対応
    • 監査と事後調査の為の、無加工の通知メッセージキャプチャに対応
    • ElasticSearch へのイベント保存に対応
    • データベース、HTTP、ファイル、Kafka、oslo.messaging が対応するメッセージキューへのイベント発行に対応
    • イベント保存を複数のデータベースに分割するオプション
    • Ceilometer は今回、イベントとしての全イベントタイプメーター収集・保存に対応しました。全イベントタイプをサンプルとして保存する機能を無効化する為に、新オプション「disable_non_metric_meters」が追加されました。詳細は、Telemetry 設定リファレンスを参照して下さい。
    • 新しいイベント章を追加して、OpenStack マニュアルの管理者ガイドが更新されました。この章には上記機能の詳細情報があります。
  • パイプライン発行対応の改善:
    • Kafka、HTTP ターゲットへのイベント・サンプル発行に対応
    • 複数キューへのデータ発行
  • メーター追加
    • Hyper-V 用のメモリ、ディスクメーター
    • LibVirt 用のディスクメーター
    • ノードマネージャーからの、電源、温度関連 IPMI メーター、他メーター
    • Ceph メーター
  • Ceilometer の UDP パブリッシャーとコレクタにおける IPv6 対応
  • ceilometer-collector 用の Gnocchi ディスパッチ対応
  • ポーリングプログラム(pollster)の自己無効化機構


アップグレード時の注意

  • 廃止予定のメーター
    • インスタンス:<flavor> メーターは Kilo で廃止予定になりました。フレーバーベースのサンプルや統計を取得する為には、以下のクエリが使用できます。
  統計:
  ceilometer statistics -m instance -g resource_metadata.instance_type
  サンプル:
  ceilometer sample-list -m instance -q metadata.instance_type=<value>


OpenStack Orchestration (Heat)

主要な新機能

アップグレード時の注意

  • 設定オプション「num_engine_workers」のデフォルト値は従来の1からCPU数ベースの値に変更されました。これは、他のプロジェクトの worker 数の設定方法と同じです。
  • 設定オプション「max_nested_stack_depth」のデフォルト値が大きくなり5になりました。
  • デフォルト値が off の新しい設定オプション「convergence」が追加されました。この機能はまだ不完全で、このオプションは off のままにしておくべきです。
  • 来たるべき主要機能(convergence)への準備として、DB スキーマに大幅な変更がありました。スキーマアップグレード中は heat-engine を停止することを推奨します。

その他(廃止予定/廃止等)

廃止予定

  • 次のリソースは廃止予定になりました: OS::Heat::HARestarter、OS::Heat::CWLiteAlarm
  • CloudWatch API (heat-api-cw)


OpenStack Database service (Trove)

主要な新機能

  • 非同期 GTID レプリケーション(MySQL 5.6 の新機能)ベースの新しいレプリケーション方式に対応
    • 1回のAPI呼び出しで、単一のマスターからの複数レプリカが作成可能
    • 新しい「eject-master」API を使用して、応答しなくなったマスターから最も新しいスレーブへフェイルオーバーができます
  • Trove ゲストマネージャーで以下のデータストアの対応が追加されました:
    • Vertica、Vertica Cluster
    • DB2
    • CouchDB
  • 現在の管理 API レイヤーの拡張:
    • 削除済み trove インスタンスの一覧表示と詳細表示を行う新しい管理 API を追加
    • RPC 機構経由でデータストアゲストエージェントへの ping を行う新しい管理 API を追加
  • Horizon が Trove インスタンスのリサイズに対応
  • ユーザーが Trove インスタンス名を編集/更新可能に
  • OpenStack プロジェクト共通のプロファイリングライブラリ(OSProfile)に対応

アップグレード時の注意

  • 廃止予定の oslo-incubator messaging コードから正式な oslo.messaging Python モジュールに移行しました。設定値変更の詳細は git.openstack.org/cgit/openstack/trove/tree/etc/trove/trove.conf.sample#n18 を参照して下さい (この変更はここで行われました)。
  • 何らかの CI でテストを行っていない既存のデータストアとストラテジーは、それぞれのモジュールの「experimental」セクションに移動されました。これらのデータストアとストラテジーは、CI での適切なテスト実行とゲートでの実行が行われるようになったら、「stable」に卒業となります。
  • 様々なデータストア用の Trove ゲストイメージの作成手順について解説した新しいドキュメントを作成しました。 http://docs.openstack.org/developer/trove/dev/building_guest_images.html


OpenStack Data Processing service (Sahara)

主要な新機能

  • 新プラグイン (機能とバージョン);
    • MapR
    • Apache Storm
    • Apache Hadoop 2.6.0 対応追加, Apache Hadoop 2.4.1 対応廃止予定
    • CDH プラグイン用の HDFS 上の新サービス追加。YARN、Spark、Oozie、HBase、ZooKeeper、その他のサービスに対応しています。
  • フローティングIPの使用量を改善する、間接 VM アクセスを追加
  • プロビジョニング進行状況の詳細が分かる、イベントログ対応を追加
  • オプションの、プラグイン単位のデフォルトのノードグループとクラスターのテンプレート
  • Horizon 更新:
    • ガイド付クラスター作成とジョブ実行
    • オブジェクト検索におけるフィルタリング
  • ノードグループテンプレートとクラスターテンプレートの編集機能を実装
  • Oozie 実行クラスターへのシェルジョブタイプ追加
  • サポートするジョブタイプ一覧の問い合わせ用の新しいジョブタイプエンドポイント


アップグレード時の注意

詳細: http://docs.openstack.org/developer/sahara/userdoc/upgrade.guide.html#juno-kilo

  • Sahara は policy.json 設定ファイルが必要になりました。


OpenStack Bare Metal service (Ironic)

主要な新機能

ステートマシン

Ironic は管理する各ノードの論理状態用の公式モデルを使用するようになりました。 [1] このステートマシンは2つの新しい処理「cleaning」「inspection」を許容します。

  • テナント間の自動ディスク削除機能はデフォルトで有効になりました。これは、「cleaning」の追加処理(ファームウェア再適用、BIOS設定リセット、等)を実行します。[2]

ハードウェアを「検査(inspect)」する方法として、サービスLAN経由と非経由の両方が利用できるようになりました。これらのメソッドは、ノードのプロパティを自動的に更新するのに使用されます。[3]

バージョンヘッダ

Ironic REST API は新しい「X-OpenStack-Ironic-API-Version」ヘッダが各 HTTP(S)リクエストに付与される事を想定しています。このヘッダは、クライアントとサーバが相互に対応インターフェースの調整を行えるようにします。[4] このヘッダがない場合、REST サービスはデフォルトの互換モードとなり、Juno クライアントと互換性のある応答を返します。但し、このモードでは Kilo で導入されたほとんどの機能へのアクセスが出来ません。

ハードウェアドライバの変更

以下のドライバが追加されました。


既存のドライバでは以下の拡張が行われました。


サードパーティーやリポジトリ外のドライバー対応では、以下の2つの拡張が行われました。

  • ドライバーは、ノードに関する独自の「内部」情報を保存できます。
  • ドライバーは、Conductor によって実行される、独自の定期処理を登録できます。
  • 「vendor_passthru」メソッドが HTTP メソッド(例:PUT、POST)に対応しました。
  • 「vendor_passthru」メソッドが REST API でディスカバリ可能になりました。

node vendor passthrudriver vendor passthru を参照して下さい。

その他の変更

  • 標準的な UUID に加えて、ノード指定に論理名を使用できるようになりました。
  • 様々なローカルディスクを持つサーバ用に、OS がインストールされるディスクデバイスの指定に影響するヒントを指定できるようになりました。
  • HTTP(S) ソースからカーネル、RAMディスク、インスタンスイメージを直接取得できるようになりました。これにより、Glance への依存性を排除する事ができます。Ironic を独立サービスとして使用する
  • REST API 要求経由で、ノードをメンテナンスモードにする事ができるようになりました。その際、オプションで「メンテナンス理由」を指定できるようになっています。

既知の問題

  • 複数の nova-compute プロセス実行は公式にはサポートされていません。
    • Ironic が(Ironic を使用する nova-compute プロセスが複数動く事を許容する)ClusteredComputeManager を含む一方、nova-compute の複数実行は実験的であり、既知の多くの問題を持っている事を考慮すべきです。
  • 「agent」デプロイ機構を使用するドライバは「rebuild --preserve-ephemeral」に対応しません。

アップグレード時の注意

  • REST API 応答ではIPMI パスワードが明示されないようになりました。この挙動は API ポリシー設定の変更で無効化出来ます。
  • ドライバの「agent」クラスは、ディスク全体ベースとパーティションベースの両方のイメージ形式に対応しました。
  • 「deploy_kernel」「deploy_ramdisk」パラメータ採用により、「pxe_deploy_kernel」「pxe_deploy_ramdisk」の driver_info パラメータは廃止予定となりました。
  • 新しい @passthru デコレータの採用により、vendor_passthru() メソッドを独自に実装するドライバは廃止予定になりました。

Juno から Kilo へ

推奨アップグレード手順がドキュメント化されています。

Icehouse "nova-baremetal" からのアップグレード方法

Icehouse の Nova "baremetal" ドライバ環境から Kilo Ironic に直接アップグレードすることは、テストされていなく、サポートされません。代わりに、以下のアップグレード手順に従ってください。

  1. Icehouse Nova "baremetal" -> Juno Nova "baremetal"
  2. Juno Nova "baremetal" -> Juno Ironic
  3. Juno Ironic -> Kilo Ironic

手順 1 と手順 2 のドキュメントが利用できます。 https://wiki.openstack.org/wiki/Ironic/NovaBaremetalIronicMigration


OpenStack Documentation

  • [1]新しい Ironic のステートマシン
  • [2]ノードクリーン
  • [3]ハードウェア検査
  • [4]REST API 「マイクロ」バージョン