Jump to: navigation, search

ReleaseNotes/Kilo

Revision as of 02:24, 3 May 2015 by Yosshy (talk | contribs) (Created page with "【注意】neutron.conf 中でロードされていない関連サービスプラグインには影響しません。")
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は大容量であまりアクセスされないデータを一つのリージョンで保存するのに適しています。

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

SwiftのECはPyECLib及びliberasurecodeに依存しています。liberasurecodeは実際のあなたの選んだライブラリで実装されているECアルゴリズムをプラガブルに利用するためのライブラリです。

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

合成トークン

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

例えば、ユーザがNovaでVMのスナップショットを保存するとします。NovaはGlanceにSwiftのあるコンテナにオブジェクトを書き込むよう命令します。この場合、そのユーザはNovaサービスの正しいトークンなしにそのスナップショットを変更できませんし、正しいユーザトークンなしにNovaサービスがそのデータを変更することはできません。データ自体はアカウント管理をシンプルにするためにユーザのカウント配下に保存されます。

完全なドキュメントは Full docs are at 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 系ノードでは、１つの vCenter 環境を（異なるホスト名を持つ）２つの異なるホストから管理しようとする際に引き起こされます。これらは 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 環境が対応している認証機構から１つを選択できるようになります。この機能を使う為には、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 のこの新機能は OpenStack 構築の将来像となるでしょう。
  • Nova
    • ハイパーバイザ上のサービスの有効・無効化に対応
    • ホストから全インスタンスをマイグレーション
    • シリアルコンソールの公開
  • Cinder
    • Cinder v2 API がデフォルトに
    • Managed/Unmanaged volume support
    • 管理／非管理ボリューム対応…管理者が既存のボリュームを（cinder が管理していないボリュームと同様） cinder の管理対象外にする事ができるようになります。
    • プロジェクト間のボリューム転送に対応
    • ボリューム暗号化メタデータに対応
  • Glance
    • 管理者によるGlanceメタデータ定義の確認/追加/変更
  • Heat
    • スタックテンプレート一覧
    • オーケストレーションリソースパネル
    • スタックのサスペンド/リジュームアクション
    • スタック作成前に指定されたスタックのプレビュー
  • Trove
    • Trove インスタンスのリサイズ -- インスタンスのフレーバーの変更
  • Ceilometer
    • CeilometerからのIPMIメータ値を表示
  • Horizon における新しい再利用可能な AngularJS ウィジェット:
    • AngularJS テーブル実装
      • テーブル描画機能…拡張可能なテーブルコンテンツ
      • 改善されたクライアント／サーバ検索
    • テーブルウィジェットの転送
  • '/' パスにおける Horizon のトップページを変更可能に

既知の問題

アップグレード時の注意

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


OpenStack Identity (Keystone)

主要な新機能

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

  • また、既に存在しているプロジェクトに対して、get-projectAPI/v3/projectsを通じて、その親子関係を取得することができます。
  • Role は、階層的なプロジェクトツリー上で、users と groups の両方に紐付けすることができます。
  • この機能はがより有用になるためには、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 認証方式を使用できるようになりました。一方で mapped、 saml2 どちらも引き続き利用可能です。
  • 連携ユーザがローカルの既存アイデンティティにマッピングできるようになりました。
  • マッピングのルールセットで指定されるグループが名前とドメインで指定可能になりました。
  • 連携認証アサーションで示されるグループが、ローカルのメンバーマッピング込みで自動的に既存のローカルグループにマッピングされるようになりました（ホワイトリスト／ブラックリストでフィルタリング可能）。

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 ミドルウェアフィルタの削除と、public_api、admin_api、api_v3、public_version_api、admin_version_api、その他 XML フィルタを含む可能性のある参照元からの削除を含みます。
  • 以前の拡張機能（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
  • Portsecurity support for the OVS ML2 Driver
  • 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 ドライバ

既知の問題

  • Kilo リリースでは、Firewall-as-a-Service (FWaaS) は依然実験段階です。
  • バグ 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）も分割された為、有効なサービスプロバイダ設定がアップグレード後に異なります（特に、デフォルトのロードバランサ (haproxy) と VPN (openswan) プロバイダが元々 neutron.conf 中で無効化されていた場合でも移行後はデフォルトで有効になります）。アップグレード後に設定を見なおして、サービスプロバイダが設計通りに反映されている事を確認して下さい。

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


その他事項 (非推奨/EOL など)

  • Deprecation
    • Brocade Monolithic plugin for Brocade's VDX/VCS series of hardware switches will be deprecated in the L-Release. The functionality provided by this plugin is now addressed by the ML2 Driver available for the VDX series of hardware. The plugin is slated for removal after this release cycle.
    • The monolithic Cisco Meta plugin for Nexus1000V will be deprecated in the L-Release. The functionality provided by this plugin is now available with the Cisco Nexus1000V ML2 mechanism driver. The monolithic plugin is slated for removal after this release cycle.

OpenStack Block Storage (Cinder)

主要な新機能

  • From this point forward any new database schema upgrades will not require restarting Cinder services right away. The services are now independent of schema upgrades. This is part one to Cinder supporting rolling upgrades!
  • Ability to add/remove volumes from an existing consistency group. Read docs for more info.
  • Ability to create a consistency group from an existing consistency group snapshot. Read docs for more info.
  • Create more fine tuned filters/weighers to set how the scheduler will choose a volume backend. Read the docs for more info.
  • Encrypted volumes can now be backed up using the Cinder backup service. Read the docs for more info.
  • Ability to create private volume types. This is perfect when you want to make volume types available to only a specific tenant or to test it before making available to your cloud. To do so use the cinder type-create <name> --is-public.
  • Oversubscription with thin provision is configurable. Read docs for more info.
  • Ability to add descriptions to volume types. To do so use cinder type-create <name> <description>
  • Cinder now can return multiple iSCSI paths information so that the connector can attach volumes even when the primary path is down (when connector's multipath feature is enabled or not enabled).

Upgrade Notes

  • The 'host' config option for multiple-storage backends in cinder.conf is renamed to 'backend_host' in order to avoid a naming conflict with the 'host' to locate redis. If you use this option, please ensure your configuration files are updated.


OpenStack Telemetry (Ceilometer)

主要な新機能

  • Support to add jitter to polling cycles to ensure pollsters are not querying service's api at the same time
  • Ceilometer API RBAC support
  • Improved Event support:
    • Multi-pipeline support to enable unique processing and publishing of events
    • Enabled ability to capture raw notification messages for auditing and postmortem analysis
    • Support for persisting events into ElasticSearch
    • Publishing support to database, http, file, kafka and oslo.messaging supported message queues
    • Option to split off the events persistence into a separate database
    • Telemetry now supports to collect and store all the event type meters as events. A new option, disable_non_metric_meters, was added to the configuration in order to provide the possibility to turn off storing these events as samples. For further information please see the Telemetry Configuration Reference
    • The Administrator Guide in OpenStack Manuals was updated with a new Events section, where you can find further information about this functionality.
  • Improved pipeline publishing support:
    • Support to publish events and samples to Kafka or HTTP targets
    • Publish data to multiple queues
  • Additional meters
    • memory and disk meters for Hyper-V
    • disk meters for LibVirt
    • power and thermal related IPMI meters, more meters from NodeManager
    • ability to meter Ceph
  • IPv6 support enabled in Ceilometer udp publisher and collector
  • Gnocchi dispatch support for ceilometer-collector
  • Self-disabled pollster mechanism


アップグレード時の注意

  • Deprecated meters:
    • The instance:<flavor> meter is deprecated in the Kilo release. In order to retrieve samples or statistics based on flavor you can use the following queries:
  statistics:
  ceilometer statistics -m instance -g resource_metadata.instance_type

  samples:
  ceilometer sample-list -m instance -q metadata.instance_type=<value>


OpenStack Orchestration (Heat)

主要な新機能

Upgrade Notes

  • The default of the configuration option "num_engine_workers" has changed from 1 to a number based on the the number of CPUs. This is now the same as the way other projects set the number of workers.
  • The default for the configuration option "max_nested_stack_depth" has been increased to 5.
  • There is a new configuration option "convergence" it is by default off. This feature is not yet complete and this option should remain off.
  • In preparation of an upcoming major feature (convergence) there have been some significant DB schema changes. It is suggested that the heat-engine is shutdown during schema upgrades.

Other Notes (Deprecation/EOL etc)

非推奨

  • The follow resources are deprecated OS::Heat::HARestarter and OS::Heat::CWLiteAlarm
  • The CloudWatch API (heat-api-cw)


OpenStack Database service (Trove)

主要な新機能

  • Support for a new replication strategy based on async GTID replication (new in MySQL 5.6)
    • We now support for creating n-replicas from a single master in one API call
    • We also support for failover from an unresponsive master to the most up-to-date slave can now be achieved using the new 'eject-master' API
  • Support for Trove guest managers to support the following new datastores:
    • Vertica, and Vertica Cluster
    • DB2
    • CouchDB
  • Extended current management API layer :
    • We now have a new management API to support listing and viewing deleted trove instances
    • We also added a new management API to ping a datastore guestagent via the RPC mechanism
  • Horizon updates to support resize of Trove instances.
  • Users now have the ability to edit/update the names of Trove instances
  • Integration with the cross-project OpenStack profiling library (OSProfiler)

アップグレード時の注意

  • We migrated from deprecated oslo-incubator messaging code to the official oslo.messaging python module. Please look at git.openstack.org/cgit/openstack/trove/tree/etc/trove/trove.conf.sample#n18 for more details on the changed config values that were added to support this, (Change)
  • Datastores and strategies that are not currently being tested by any CI have been moved into an 'experimental' section in their respective modules. Once these datastores and strategies have appropriate tests exercising and gating against them in CI, they will be graduated to 'stable'.
  • Added new documentation to help with the process of building trove guest images for different datastores at http://docs.openstack.org/developer/trove/dev/building_guest_images.html


OpenStack Data Processing service (Sahara)

主要な新機能

  • New plugins, their features and versions:
    • MAPR
    • Apache Storm
    • Apache Hadoop 2.6.0 was added, Apache Hadoop 2.4.1 deprecated
    • New services for CDH plugin added up to HDFS, YARN, Spark, Oozie, HBase, ZooKeeper and other services
  • Added indirect VM access for better utilization of floating IPs
  • Added event log support to have detailed info about provisioning progress
  • Optional default node group and cluster templates per plugin
  • Horizon updates:
    • Guided cluster creation and job execution
    • Filtering on search for objects
  • Editing of Node Group templates and Cluster templates implemented
  • Added Shell Job Type for clusters running Oozie
  • New Job Types endpoint to query list of the supported Job Types


アップグレード時の注意

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

  • Sahara now requires policy.json configuration file.


OpenStack Bare Metal service (Ironic)

主要な新機能

State Machine

Ironic now uses a formal model for the logical state of each node it manages.[1] This has enabled the addition of two new processes: cleaning and inspection.

  • Automatic disk erasure between tenants is now enabled by default. This may be extended to perform additional cleaning steps, such as re-applying firmware, resetting BIOS settings, etc.[2]
  • Both in-band and out-of-band methods are available to inspect hardware. These methods may be used to update Node properties automatically.[3]

Version Headers

The Ironic REST API expects a new X-OpenStack-Ironic-API-Version header be passed with each HTTP[S] request. This header allows client and server to negotiate a mutually supported interface.[4] In the absence of this header, the REST service will default to a compatibility mode and yield responses compatible with Juno clients. This mode, however, prevents access to most features introduced in Kilo.

Hardware Driver Changes

The following new drivers were added:


The following enhancements were made to existing drivers:


Support for third-party and out-of-tree drivers is enhanced by the following two changes:

  • Drivers may store their own "internal" information about Nodes.
  • Drivers may register their own periodic tasks to be run by the Conductor.
  • vendor_passthru methods now support additional HTTP methods (eg, PUT and POST).
  • vendor_passthru methods are now discoverable in the REST API. See node vendor passthru and driver vendor passthru

Other Changes

  • Logical names may be used to address Nodes, in addition to their canonical UUID.
  • For servers with varied local disks, hints may be supplied that affect which disk device the OS is provisioned to.
  • Support for fetching kernel, ramdisk, and instance images from HTTP[S] sources directly has been added to remove the dependency on Glance. Using ironic as a standalone service
  • Nodes may be placed into maintenance mode via REST API calls. An optional maintenance reason may be specified when doing so.

既知の問題

  • Running more than one nova-compute process is not officially supported.
    • While Ironic does include a ClusteredComputeManager, which allows running more than one nova-compute process with Ironic, it should be considered experimental and has many known problems.
  • Drivers using the "agent" deploy mechanism do not support "rebuild --preserve-ephemeral"

アップグレード時の注意

  • IPMI Passwords are now obfuscated in REST API responses. This may be disabled by changing API policy settings.
  • The "agent" class of drivers now support both whole-disk and partition based images.
  • The driver_info parameters of "pxe_deploy_kernel" and "pxe_deploy_ramdisk" are deprecated in favour of "deploy_kernel" and "deploy_ramdisk".
  • Drivers implementing their own version of the vendor_passthru() method has been deprecated in favour of the new @passthru decorator.

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]New Ironic State Machine
  • ↑ [2]Node Cleaning
  • ↑ [3]Hardware Inspection
  • ↑ [4]REST API "micro" versions
    • Retrieved from "https://wiki.openstack.org/w/index.php?title=ReleaseNotes/Kilo/ja&oldid=79418"