Jump to: navigation, search

Difference between revisions of "ReleaseNotes/Havana/ja"

(→‎既知の問題)
(→‎プロパティ（属性）保護)
Line 264: Line 264:
 
Image Service のパブリック API コールを介したメタプロパティへのアクセスは、プロパティ保護設定ファイル（glance-api.conf ファイル中で指定）を使用して特定のユーザのグループに制限する事ができます。例：
 
Image Service のパブリック API コールを介したメタプロパティへのアクセスは、プロパティ保護設定ファイル（glance-api.conf ファイル中で指定）を使用して特定のユーザのグループに制限する事ができます。例：
 
* 全プロパティ操作を管理者のみに制限。
 
* 全プロパティ操作を管理者のみに制限。
−
* 管理者と課金ロールを持つユーザの両方に、``x_billing_code_`` で始まる全プロパティの読取・修正権限を付与。
+
* 管理者と課金ロールを持つユーザの両方に、``x_billing_code_`` で始まる全プロパティの読取・修正権限を付与。 [https://blueprints.launchpad.net/glance/+spec/api-v2-property-protection blueprint]
−
[https://blueprints.launchpad.net/glance/+spec/api-v2-property-protection blueprint]
 
  
 
====Registry API====
 
====Registry API====

Revision as of 15:20, 18 October 2013

Contents

OpenStack 2013.2 (Havana) リリースノート

In this document you'll find a description of key new features, known bugs and upgrade tips for the 2013.2 (Havana) release of OpenStack.

OpenStack Object Storage (Swift)

主な新機能

  • Global clusters support

The "region" concept introduced in Swift 1.8.0 has been augmented with support for using a separate replication network and configuring read and write affinity. These features combine to offer support for a single Swift cluster spanning wide geographic area.

  • Added config file conf.d support

Allow Swift daemons and servers to optionally accept a directory as the configuration parameter. This allows different parts of the config file to be managed separately, eg each middleware could use a separate file for its particular config settings.

  • Disk performance

The object server now can be configured to use threadpools to increase performance and smooth out latency throughout the system. Also, many disk operations were reordered to increase reliability and improve performance.

  • Added support for pooling memcache connections
  • Much faster calculation for choosing handoff nodes

Significant bugs fixed

  • Fixed bug where memcache entries would not expire
  • Fixed issue where the proxy would continue to read from a storage

server even after a client had disconnected

  • Fix issue with UTF-8 handling in versioned writes

Additional operational polish

  • Set default wsgi workers to cpu_count

Change the default value of wsgi workers from 1 to auto. The new default value for workers in the proxy, container, account & object wsgi servers will spawn as many workers per process as you have cpu cores. This will not be ideal for some configurations, but it's much more likely to produce a successful out of the box deployment.

  • Added reveal_sensitive_prefix config setting to filter the auth token

logged by the proxy server.

  • Added support to replicating handoff partitions first in object

replication. Can also configure now many remote nodes a storage node must talk to before removing a local handoff partition.

  • Added crossdomain.xml middleware. See

http://docs.openstack.org/developer/swift/crossdomain.html for details

  • Numerous improvements to get Swift running under PyPy

既知の問題

  • If you're using cells, there's an issue when deleting instances. Different than Grizzly, deleting instances will delete them immediately from the top level (API) cell before telling the child cell to delete the instance. This was not intended. A side effect of this is that delete.start and delete.end notifications will be sent. If the instance delete in the child cell succeeds, a 2nd delete.start and delete.end notification will be sent. If it does not, the DBs end up out of sync where the instance appears gone from the API cell, but still exists in the child cell. The natural healing code built into cells will end up correcting this and restoring the instance in the API cell DB after some time, depending on healing configuration. This bug will be corrected in havana-stable shortly after release.
  • Check http://bugs.launchpad.net/nova

アップグレード時の注意

Read full change log notes at https://github.com/openstack/swift/blob/master/CHANGELOG to see any config changes that would affect upgrades.

As always, Swift can be upgraded with no downtime.

OpenStack Compute (Nova)

主な新機能

API

  • Compute (Nova) REST API に実験的な新バージョン (v3) が追加されました。新しいバージョンでは、多くの API の整理が行われるとともに、 拡張 API にバージョンをつけて実装するためのフレームワークが入ります。 (blueprint)
  • 以下の拡張 API (extension) が Compute (Nova) REST API に追加されました。
    • CellCapacities: Cell 内の RAM 総量と未使用の RAM 容量を取得できるようになりました。 (blueprint)
    • ExtendedFloatingIps: Floating IP 追加コマンドに fixed_address パラメーター (省略可能) が追加され、 Floating IP に関連付ける固定 IP を指定できるようになりました。 (blueprint)
    • ExtendedIpsMac: サーバーのレスポンスに MAC アドレスが追加されました。(blueprint)
    • ExtendedQuotas: デフォルト値と異なるテナントのクォータを削除し、クォータのデフォルト値に戻せます。 (blueprint)
    • ExtendedServices: サービスが無効になっている理由を設定・取得できます。 (blueprint)
    • ExtendedVolumes: インスタンス情報に接続中のボリュームが追加されました。 (blueprint)
    • Migrations: 進行中のリサイズやマイグレーションの一覧を Cell やリージョン毎に取得できます。 (blueprint)
    • ServerUsage: インスタンスの詳細表示 (instance show) で launched_at と terminated_at の値を取得できます。 (blueprint)
    • UsedLimitsForAdmin: 管理 API でテナント毎のクオータ上限を取得できます。 (blueprint)
  • Compute サービスの EC2 API が返すエラーコードの 公式の EC2 API との一貫性が向上しました。 (blueprint)

Cell

  • Cell スケジューラでフィルターと重み付けがサポートされました。設定の [cells] グループの新規オプション scheduler_filter_classes と scheduler_weight_classes で設定できます。 ram_by_instance_type と weight_offset モジュールが新規に追加され、前のリリースで使われていた Cell のランダム選択は削除されました。また、フィルタークラス TargetCellFilter により、管理者がスケジューラーヒントを使って特定の Cell にインスタンスを作成するように指示できます。これにより概念上は Cell スケジューリングは既存のホストスケジューリングと同様に動作するようになります。 (blueprint)
  • Cell 内での仮想マシンインスタンスのライブマイグレーションがサポートされました。 Cell 間でのライブマイグレーションはサポートされていません。(blueprint)
  • Cell 使用時に Nova から Cinder が利用できるようになりました。 (blueprint)

Compute

全般
  • 利用可能なハイパーバイザーに Docker を使ったコンテナの作成・管理が追加されました。 (blueprint)
  • インスタンスを "shelve" する (棚上げにする) 機能が追加されました。この機能を使うと、長期間停止されたインスタンスをハイパーバイザーから追い出し、リソースを解放できます。(blueprint)
  • vendor_data セクションがメタデータサービスとコンフィグドライブ機能に追加されました。これにより、メタデータを拡張してベンダー固有やサイト固有のデータをゲストで利用できるようになります。 (blueprint)
ベアメタルドライバー
  • Tilera のベアメタルプロビジョニングに対応したバックエンドがベアメタルドライバーに追加されました。 (blueprint)
Hyper-V ドライバー
  • Windows Server / Hyper-V Server 2012 R2 のサポート (blueprint)
  • VHDX フォーマットのサポート (blueprint)
  • エフェメラルストレージのサポート (blueprint).
  • Ceilometer 連携用のコンピュート情報のサポート (blueprint).
libvirt (KVM) ドライバー
  • QEMU ゲストエージェント (qemu-guest-agent) のサポート。 * hw_qemu_guest_agent プロパティが "yes" で作成されたゲストで有効になります。 ( blueprint).
  • 物理コンピュートノードから仮想ゲストへの PCI デバイスのパススルーのサポート。現在のところ、パススルーが動作する実装は libvirt ドライバーだけである。 (base blueprint, libvirt blueprint).
  • libvirt を使ったハイパーバイザーでの Cinder からの QoS パラメータの抽出とそれに基づくディスクアクセスのレート制限のサポート (blueprint).
  • RBD をイメージ格納バックエンドとしてサポート (blueprint).
PowerVM ドライバー
  • ハードリブートに対応 (change).
vmwareapi (VMWare) ドライバー
  • 複数クラスターの管理をサポート (blueprint)
  • イメージのクローン方法指定 - イメージに対してリンクによるクローンかフルクローンイメージのどちらを使うかを指定可能 (blueprint)
  • コンフィグドライブのサポート (blueprint)
XenServer ドライバー
  • Supports showing a log of a server console (blueprint)
  • Support for splitting up large ephemeral disks into 1024GB or 2000GB chunks to work around VHD max disk size limitations (blueprint)
  • Allow images to have the setting of AutoDiskConfig=disabled, to mean users are unable to set AutoDiskConfig=Manual on these images and servers (blueprint)
  • Improvements to how nova communicates with the Nova agent, so you are able to use both cloud-init and the Nova agent in the same cloud. (blueprint)
  • Ability to boot VMs into a state where they are running a linux distribution installer, to help users build their own custom images (blueprint)
  • Experimental support for XenServer core, and running nova-compute in a XenServer core Dom0. (blueprint)
  • Experimental support for using the LVHD storage SR, and support for booting from compressed raw glance images (blueprint)
  • Much work to improve stability and supportability. Examples include the ability to configure the compression ratio used for snapshots sent to glance and auto rollback of errors during the Resize down of servers due to disks been too small for the destination size.

クォータ

  • クォータのデフォルト値が編集できるようになりました。以前はクォータのデフォルト値は固定値でした。 nova quota-class-update default <key> <value> コマンドで、クォータのデフォルト値を更新できます。(blueprint)
  • Quotas may now be defined on a per-user basis (blueprint)
  • ユーザー単位のクォータが定義できるようになりました。 (blueprint)
  • 特定のテナントやユーザーに対するクォータが削除できるようになりました。その場合、そのテナントやユーザーのクォータはデフォルト値に戻ります。 (blueprint)

ネットワーク

  • ネットワークと IP アドレスの割当がインスタンスの用意などの他の操作と並行して行われるようになり、起動時間が短縮されました。

(blueprint)

  • インスタンスに割り当てられたコンピュートノードのホスト名を Nova から Neutron に渡すようになりました。 Neutron プラグインはこの情報を使って、コンピュートノードの物理ネットワーク設定を必要に応じて変更します。 (blueprint).

通知 (notifications)

  • ホストアグリゲートの作成、削除、拡大、縮小やそれ以外の更新の際の通知が行われるようになりました。 (blueprint).
  • インスタンス作成失敗時に通知が行われるようになりました。 (blueprint).

Scheduler

  • Added force_nodes to filter properties, allowing operators to explicitly specify the node for provisioning when using the baremetal driver (blueprint).
  • Added the ability to make the IsolatedHostsFilter less restrictive, allowing isolated hosts to use all images, by manipulating the value of the new restrict_isolated_hosts_to_isolated_images configuration directive in nova.conf (blueprint).
  • Added a GroupAffinityFilter as a counterpart to the existing GroupAntiAffinityFilter. The new filter allows the scheduling of an instance on a host from a specific group of hosts (blueprint).
  • Added the ability for filters to set the new run_filter_once_per_request parameter to True if their filtering decisions are expected to remain valid for all instances in a request. This prevents the filter having to be re-run for each instance in the request when it is unnecessary. This setting has been applied to a number of existing filters (blueprint).
  • Added per-aggregate filters AggregateRamFilter and AggregateCoreFilter which enforce themselves on host aggregates rather than globally. AggregateDiskFilter will be added in a future release (blueprint).
  • Scheduler performance has been improved by removing the periodic messages that were being broadcasted from all compute nodes to all schedulers (blueprint).
  • Scheduler performance has been improved by allowing filters to specify that they only need to run once for a given request for multiple instances (blueprint).

Storage

  • Attached Cinder volumes can now be encrypted. Data is decrypted as needed at read and write time while presenting instances with a normal block storage device (blueprint).
  • Added the ability to transparently swap out the Cinder volume attached to an instance. While the instance may pause briefly while the volume is swapped no reads or writes are lost (blueprint).
  • When connecting to NFS or GlusterFS backed volumes Nova now uses the mount options set in the Cinder configuration. Previously the mount options had to be set on each Compute node that would access the volumes (blueprint).
  • Added native GlusterFS support. If qemu_allowed_storage_drivers is set to gluster in nova.conf then QEMU is configured to access the volume directly using libgfapi instead of via fuse (blueprint).
  • QEMU assisted snapshotting is now used to provide the ability to create cinder volume snapshots, even when the storage backing storage in use does not support them natively, such as GlusterFS (blueprint).
  • The iSER transport protocol is now supported for accessing storage, providing performance improvements compared to using iSCSI over TCP (blueprint).

Conductor

  • conductor は複数のワーカースレッドを起動し、並列で動作できるようになりました。起動するスレッド数はnova.conf の workers の値で決まります。 (blueprint).

内部的な変更

  • Nova は Oslo が提供する共通サービス基盤を使用するようになりました。 (blueprint)
  • データベースマイグレーションが必要なバグ修正をバックポートできるように変更が行われました。 (blueprint)
  • Nova システムのライブアップグレードのサポートに向け非常にたくさんの進展がありました。 Havana では、サービス間で送信されるメッセージのバージョンの制御 (nova.conf の [upgrade_levels] セクションを参照) (blueprint) と、コードとデータベーススキーマの詳細の分離を容易にするオブジェクト層 (blueprint) などの改良が行われました。

既知の問題

  • cell を使っている場合、インスタンスの削除時に問題があります。 Grizzly と違い、インスタンスの削除を行うと、 child cell にそのインスタンスの削除を通知する前にインスタンスは最上位の (API) cell から即座に削除されてしまいます。これは意図した動作ではありません。 この副作用として delete.start と delete.end 通知が送信されます。 child cell でのインスタンス削除が成功すると、2つ目の delete.start と delete.end 通知が送信されます。失敗した場合は、データベースは同期できていない状態となり、インスタンスは API cell からは消えているが、 child cell には存在したままになってしまいます。このバグは、リリース後すぐに havana-stable で修正される予定です。
  • 既知の問題については http://bugs.launchpad.net/nova を確認してください。

アップグレード時の注意

  • Note that periodic tasks will now run more often than before. The frequency of periodic task runs has always been configurable. However, the timer for when to run the task again was previously started after the last run of the task completed. The tasks now run at a constant frequency, regardless of how long a given run takes. This makes it much more clear for when tasks are supposed to run. However, the side effect is that tasks will now run a bit more often by default. (https://review.openstack.org/#/c/26448/)
  • The security_groups_handler option has been removed from nova.conf. It was added for Quantum and is no longer needed. (https://review.openstack.org/#/c/28384/)
  • This change should not affect upgrades, but it is a change in behavior for all new deployments. Previous versions created the default m1.tiny flavor with a disk size of 0. The default value is now 1. 0 means not to do any disk resizing and just use whatever disk size is set up in the image. 1 means to impose a 1 GB limit. The special value of 0 is still supported if you would like to create or modify flavors to use it. (https://review.openstack.org/#/c/27991/).
  • A plugins framework has been removed since what it provided was possible via other means. (https://review.openstack.org/#/c/33595)
  • The notify_on_any_change configuration option has been removed. (https://review.openstack.org/#/c/35264/)
  • The compute_api_class option has been deprecated and will be removed in a future release. (https://review.openstack.org/#/c/28750/)
  • Nova now uses Neutron after Quantum was renamed. (https://review.openstack.org/#/c/35425/)
  • Nova will now reject requests to create a server when there are multiple Neutron networks defined, but no networks specified in the server create request. Nova would previously attach the server to *all* networks, but consensus was that behavior didn't make sense. (https://review.openstack.org/#/c/33996/)
  • The vmware configuration variable 'vnc_password' is now deprecated. A user will no longer be required to enter as password to have VNC access. This now works like all other virt drivers. (https://review.openstack.org/#/c/43268/)


OpenStack Image Service (Glance)

主な新機能

プロパティ（属性）保護

特定のユーザグループに任意のエンティティの異なるプロパティを作成・更新・読取する権限を付与できます。 Image Service 中でイメージのプロパティには２つのタイプがあります：

  • コアプロパティ（イメージスキーマにより指定）
  • メタプロパティ（イメージに付与可能な任意のキー・バリューのペア）

Image Service のパブリック API コールを介したメタプロパティへのアクセスは、プロパティ保護設定ファイル（glance-api.conf ファイル中で指定）を使用して特定のユーザのグループに制限する事ができます。例：

  • 全プロパティ操作を管理者のみに制限。
  • 管理者と課金ロールを持つユーザの両方に、``x_billing_code_`` で始まる全プロパティの読取・修正権限を付与。 blueprint

Registry API

A new API has been created for the Registry service (db_api compliant) using RPC-over-HTTP. The API:

  • Allows Glance to continue to support legacy deployments that were using the earlier registry service. Glance v2 dropped completely the use of a registry service, which in some cases could result in a security vulnerability (all database parameters had to be present in glance-api.conf if deployed as a 'public' service).
  • Makes it easier to implement new methods to the database API without having to modify the registry's API.

blueprint

Updates include a registry database driver that talks to a remote registry service, which in turn talks directly to a database back end. The registry service implements all the database API public functions that are actually used from outside the API. The Image Service's API v2 must be enabled, and the Image Service client must point to this. blueprint

Storage Support

The Image Service now supports the following for back-end storage:

  • Sheepdog. The Image Service can now store images in a backend Sheepdog cluster. Sheepdog is an open-source project, offering a distributed storage system for QEMU.

"Sheepdog Website" blueprint

  • Cinder. OpenStack Cinder can now be used as a block-storage backend for the Image Service. blueprint
  • GridFS. The Image Service now supports the GridFS distributed filesytem. Support is enabled using the new .conf options mongodb_store_uri and mongodb_dtore_db. GridFS locations with the form `gridfs://<IMAGE>` are supported. "GridFS Website" blueprint

Multiple Image Locations

Image service images can now be stored in multiple locations. This enables the efficient consumption of image data and the use of backup images for the event of a primary image failure. blueprint

Related updates include:

  • A policy layer for locations APIs, to enable the policy checks for changing image locations. blueprint
  • Direct URL metadata. Each Image Service storage system can now store location metadata in the image location database, enabling it to return direct URL specific meta-data to the client when direct_url is enabled. For example, given a file://URL, the NFS exporting host, the mount point, and the FS type can now be returned to the client. blueprint
  • Support for multiple locations when downloading images. This allows API clients to consume images from multiple backend store. blueprint
  • Indexed checksum image property. The checksum image property is now indexed allowing users to search for an image by specifying the checksum. blueprint
  • Scrubber update. The scrubber is a utility that cleans up images that have been deleted. The scrubber now supports multiple locations for 'pending_delete' image. blueprint
  • Metadata checking. Can now enable the checking of metadata at the image location proxy layer when the location is changed. blueprint

But wait, there's more!

  • Configurable container and disk formats. Glance previously only supported a specific set of container and disk formats, which were rarely the actual set of formats supported by any given deployment. The set of acceptable container and disk formats can now be configured. blueprint
  • Storage Quota. Users can now be limited to N bytes (sum total) across all storage systems (total_storage_quota configured in .conf file). blueprint
  • Membership Policy. Policy enforcement has been added to membership APIs (similar to image/location policy enforcement). New policies include 'new_member', 'add_member', 'get_member', 'modify_member', 'get_members', and 'delete_member'. blueprint

既知の問題


OpenStack Dashboard (Horizon)

リリース概要

Havana リリースにて3つの新しいプロジェクトがサポートされるようになりました。 そして幾つかの新しい機能が既存のプロジェクトに対して追加されました。まず、 管理者・ユーザー双方にとってユーザエクスペリエンスが改善されました。 コミュニティは成長し続けています。Havana は OpenStack Dashboard プロジェクト にとって最善のリリースだと言えるでしょう。


ハイライト

新機能

Heat

OpenStack オーケストレーションプロジェクト Heat が Havana にてデビューしました。 Horizon は Heat の全ての機能をサポートします。特筆するところとして Heat テンプレートフォーマット , トポロジー仮想化, そしてリソース検査からの動的なフォーム生成機能をサポートしています。

Ceilometer

また Havana では OpenStack Metering プロジェクトである Ceilometer がデビューしました。 Horizon 最初の Ceilometer のサポート機能として管理者がクラウドリソースの使用量を指示 出来るようになりました。またシステムの利用状況の確認を管理者が理解しやすくなりました。


Domains, Groups そして Identiry API v3 サポート

Identify サービス Keystone v3 API への対応と共に Horizon は Domains, Groups, Roles の管理と Domains, Groups, Domain ベース認証そして Domain コンテキストスイッチに 対する割り当て機能をサポートします。


Trove データベース

OpenStack Database as a Service プロジェクトである Trove が Havana から インキュベーションを卒業しました。Trove データベースのプロビジョニング・管理そしてバックアップ を OpenStack ダッシュボードから可能にしてくれた方々に対して感謝します。

Nova 機能

幾つもの OpenStack コンピュート (Nova) の新機能が Horizon でサポートになりました。 Havana リリースの新しい機能は下記のとおりです。


  • デフォルトクオータの編集
  • 管理者のインスタンスパスワードの初期化機能
  • アベイラビリティゾーンのサポート
  • リージョンサポートの改善
  • インスタンスサイズの編集
  • ボリュームからの起動機能の改善
  • プロジェクト単位でのフレーバ機能サポート


これらの機能はどこで、いつ、どのようにインスタンスが稼働したのかをより良く制御します。


Neutron 機能

幾つもの重要な OpenStack ネットワーキング (Neutron) に対する機能が Havana から追加されました。主な機能は下記のとおりです。

  • VPN as a Service
  • Firewall as a Service
  • 対話的なネットワークトポロジ編集機能
  • Neutron, Nova network 間でのセキュリティグループとクオータ機能

これらは Neutron で SDN を構築する際にとても柔軟に機能します。


ユーザエクスペリエンスの改善

自己パスワード変更機能

Ideintify API 2.0 (Keystone) の変更でユーザは自分のパスワードを管理者権限を要することなく出来るように なりました。これは今まで以上にセキュリティ的に強固でありユーザに利便性をもたらします。この機能は Identify API v3 ではまだ実装されていません。


改善された管理者情報構成

管理者向けダッシュボードの幾つかの区分にてグループ情報がより論理的になりました。 また付け加えて、管理者がホストの状態・ホストのアグリゲーツ・アベイラビリティゾーンとの 関連性をより理解しやすくなりました。


ユーザログアウトのメッセージ改善

幾つかの新しい指示器が追加になりました。これはユーザが不意にログアウトした際に何故かを ユーザに通達するものです。これらの指示器はユーザセッションが破棄された際、またタイムアウト・ 認証が許可されない区分へのアクセスがあった際に役立ちます。


セキュリティグループテンプレート

今まではセキュリティグループの編集にうんざいるすような作業が必要でした。Horizon チームは 予め設定されたテンプレートを用意することで2クリックにて設定出来るようにしました。これらの ルールは SECURITY_GROUP_RULES 設定項にあります。


コミュニティ

翻訳チーム

OpenStack 翻訳チームは Havana リリースに深く関わり Horizon は今までで一番の品質を保てました。 翻訳チームのコミュニティ構築の成功にお祝い申し上げます。


ユーザエクスペリエンスグループ

OpenStack ユーザエクスペリエンスチームの誕生は OpenStack の UX 改善を形成しました。彼らは OpenStack ダッシュボードの設計と改善に欠かせない存在となりました。

Under The Hood

LESS コンピレーション

Python コミュニティの LESS サポートが Horizon における NodeJS の削除を押し進めました。 我々は lesscpy モジュールをスタイルシートの LESS にコンパイルすることが出来ます。


Role ベースのアクセスコントロール

Horizon はその他の OpenStack プロジェクトの policy.json を利用するよう変貌を遂げようとしています。 policy.json はダッシュボードのアクセスコントロールを施行します。これはアクセスコントロールがより 容易に編集でき、元となる OpenStack プロジェクトと Horizon との間での同期を維持することに役立ちます。 がしかしこの機能は現在 Keystone と Nova の一部に関してのみサポートされています。フルサポートは次期 リリースにて予定されています。これらの機能を有効にするには POLICY_FILES_PATH と POLICY_FILES を 設定することで可能になります。

Other Improvements and Fixes

  • Swift container and object metadata are now supported.
  • New visualizations for utilization and quotas.
  • The Cisco N1K Router plugin's additional features are available through a special additional dashboard when enabled and supported in Neutron.
  • Support for self-signed or other specified SSL certificate checking.
  • Glance image types are now configurable.
  • Sorting has been improved in many places through the dashboard.
  • API call efficiency optimizations.
  • Required fields in forms are now better indicated.
  • Session timeout can now be enabled to log out the user after a period of inactivity as a security feature.
  • Significant PEP8 and code quality compliance improvements.
  • Hundreds of bugfixes and minor user experience improvements.

アップグレード時の注意

Allowed Hosts

For production deployments of Horizon you must add the ALLOWED_HOSTS setting to your settings.py or local_settings.py file. This setting was added in Django 1.5 and is an important security feature. For more information on it please consult the local_settings.py.example file or Django's documentation.

Enabling Keystone and Neutron Features

If you have existing configurations for the OPENSTACK_KEYSTONE_BACKEND or OPENSTACK_NEUTRON_NETWORK settings, you will want to consult the local_settings.example.py file for information on the new options that have been added. Existing configurations will continue to work, but may not have the correct keys to enable some of the new features in Havana.

既知の問題と制限

Session Creation and Health Checks

If you use a health monitoring service that pings the home page combined with a database-backed session backend you may experience excessive session creation. This issue is slated to be fixed soon, but in the interim the recommended solution is to write a periodic job that deletes expired sessions from your session store on a regular basis.

Deleting large numbers of resources simultaneously

Using the "select all" checkbox to delete large numbers of resources at once can cause network timeouts (depending on configuration). This is due to the underlying APIs not supporting bulk-deletion natively, and consequently Horizon has to send requests to delete each resource individually behind the scenes.

Conflicting Security Group Names With Neutron

Whereas Nova Network uses only the name of a security group when specifying security groups at instance launch time, Neutron can accept either a name or a UUID. In order to support both, Horizon passes in the name of the selected security groups. However, due to some data-isolation issues in Neutron there is an issue that can arise if an admin user tries to specify a security group with the same name as another security group in a different project which they also have access to. Neutron will find multiple matches for the security group name and will fail to launch the instance. The current workaround is to treat security group names as unique for admin users.

Backwards Compatibility

The Havana Horizon release should be fully compatible with both Havana and Grizzly versions of the rest of the OpenStack integrated projects (Nova, Swift, etc.). New features in other OpenStack projects which did not exist in Grizzly will obviously only work in Horizon if the rest of the stack supports them as well.

Overall, great effort has been made to maintain compatibility for third-party developers who have built on Horizon so far.


OpenStack Identity (Keystone)

主な新機能

  • 導入の柔軟性の改善
    • 「assignments」ドライバーにより決定される認可データ (テナント/プロジェクト、ロール、ロール割り当て。例: SQL) を、「identity」ドライバーにより決定される認証データ (ユーザー、グループ。例: LDAP) と別のバックエンドに保存できるようになりました。
    • 「credentials」ドライバーにより決定されるクレデンシャル (例: ec2 トークン) を認証データと別のバックエンドに保存できるようになりました。
    • よりきめ細かい RBAC ポリシールール (例: API リクエスト / レスポンス内容の属性項目に基づいたルール) を指定できるようになりました。
    • REMOTE_USER を用いた外部認証のプラグイン可能な処理。
    • トークン生成がプラグイン可能になり、トークンの永続性と分離されました。トークン生成は現在、UUID ベースと PKI ベースがあります。運用者は keystone.token.provider.Provider インターフェースの独自実装を作成でき、それを使用するよう keystone に [token] provider と設定できるようになりました。その結果、この新しい設定オプションのため、[signing] token_format が非推奨になりました。
    • Apache httpd の後ろの導入に対する最高級のサポート
  • New deployment features
    • Ability to cache the results of driver calls in a key-value store (for example, memcached or redis)
    • keystone-manage token_flush command to help purge expired tokens
  • New API features
    • Delegated role-based authorization to arbitrary consumers using OAuth 1.0a
    • API clients can now opt out of the service catalog being included in a token response
    • Domain role assignments can now be inherited by that domain's projects
    • Aggregated role assignments API
    • External authentication providers can now embed a binding reference into tokens such that remote services may optionally validate the identity of the user presenting the token against an presented external authentication mechanism. Currently, only kerberos is supported.
    • Endpoints may now be explicitly mapped to projects, effectively preventing certain endpoints from appearing in the service catalog for certain based on the project scope of a token. This does not prevent end users from accessing or using endpoints they are aware of through some other means.
  • Event notifications emitted for user and project/tenant create, update, and delete operations
  • General performance improvements
  • The v2 and v3 API now use the same logic for computing the list of roles assigned to a user-project pair during authentication, based on user+project, group+project, user+domain-inherited, and group+domain-inherited role assignments (where domain-inherited role assignments allow a domain-level role assignment to apply to all projects owned by that domain). The v3 API now uses a similar approach for computing user+domain role assignments for domain-scoped tokens.
  • Logs are handled using a common logging implementation from Oslo-incubator, consistent with other OpenStack projects
  • SQL migrations for extensions can now be managed independently from the primary migration repository using keystone-manage db_sync --extension=«extension-name».

既知の問題

  • six v1.4.1 or higher is an undocumented requirement (bug 1237089). Without six, Keystone will fail on startup with either ImportError: No module named six or pkg_resources.DistributionNotFound: six.
  • An experimental implementation of domain-specific identity backends (for example, a unique LDAP configuration per domain) was started in Havana but remains incomplete and will be finished during Icehouse.

OpenStack Network Service (Neutron)

主な新機能

New Name

The OpenStack Networking project has a new name in this release: Neutron. The Havana release will run using configuration files from Grizzly Quantum; however the usage of Quantum is deprecated and deployers should update all references at their earliest opportunity. Support for the Quantum configuration files and executable names will dropped in 2014.1 (Icehouse).

Advanced Services

Neutron added two new advanced services during the latest development cycle and revised the load balancer service.

Load Balancer (LBaaS) Previously released as experimental features the in 2013.1 (Grizzly) release, the load balancing service and API extensions are now suitable for deployment. This release ships an updated API and with HAProxy driver support. Vendor drivers are expected in Icehouse and Radware has already made an out of tree Havana compatible driver available for download. The load balancing service can run on multiple network nodes.

VPN (VPNaaS) Site-to-Site IPSec VPNs are now supported via the VPN service plugin. The VPN API supports IPSec and and L3 agent ships with an OpenSwan driver.

Firewall (FWaas)A new edge firewall service is included in this release. The firewall service enable tenant to configure security in depth as rules can be applied both at the edge via the firewall API and on the VIF via the security group API. The FWaaS API and drivers are considered experimental as the Neutron will continue development during the next release cycle. The team welcomes community feedback on this extension.

New Plugins

Modular Layer 2 (ML2) The Modular Layer 2 (ML2) plugin is a new OpenSource plugin to Neutron. This plugin is a framework allowing OpenStack Networking to simultaneously utilize the variety of layer 2 networking technologies found in complex real-world data centers. It currently works with the existing Open vSwitch, Linux Bridge, and L2 agents. The ML2 plugin supports local, flat, VLAN, GRE and VXLAN network types via a type drivers and different mechanism drivers. There are vendor drivers available for Arista, Cisco Nexus, Hyper-V, and Tail-f NCS. ML2 is a replacement for the Linux Bridge and Open vSwitch plugins which are now considered deprecated. More ML2 information

Other Features

  • Support for PXE Boot Options in when creating a port
  • Improved translation support

既知の問題

Upgrades from Grizzly

Starting the neutron-server after upgrading code, but prior to migration will result in some database models being created without the proper migrations occurring. The following upgrade setups should be taken to ensure a properly upgraded database.

  • Ensure that the database is stamped for Grizzly prior to stopping service.quantum-db-manage --config-file /path/to/quantum.conf --config-file /path/to/plugin/conf.ini stamp grizzly
  • Stop quantum-server and deploy the Neutron code Do not start the neutron-server at this time.
  • Run Havana Migration neutron-db-manage --config-file /path/to/quantum.conf --config-file /path/to/plugin/conf.ini upgrade havana
  • Start neutron-server

Agents May Report a Different Host Name

Neutron switched the method to determine a host's name from using the host's FQDN to the result returned by the gethostname(2) call. The change was made to be consistent with the rest of OpenStack. The hostname reported by an agent may be different and will change after the agents are updated to Havana. If so, it is necessary to reschedule all networks onto the new L3 and DHCP agent names to restore service. The change will results in a brief data plane outage will while the deployer reschedules the network.

L3 Agent No Longer Defaults to Sending Gratuitous ARPs

The L3 Agent previous defaults to sending gratuitous ARPs. The calls to send the gratuitous ARPs cause kernel panics when deployed using network namespaces on some distributions. Deployers may enable gratuitous ARP by setting send_arp_for_ha=3 in the L3 Agent's configuration file.

Firewall as a Service

The experimental FWaaS API extension only supports one active policy per tenant. The behavior will change in the during the Icehouse development cycle to allow for different policies to be attached to different tenant routers.

アップグレード時の注意

  • Changes to neutron-dhcp-agent require you to first upgrade your dhcp-agents. Then wait until the dhcp_lease time has expired. After waiting at least dhcp_lease time, update neutron-server. Failure to do this may lead to cases where an instance is deleted and the dnsmasq process has not released the lease and neturon allocates that ip to a new port. (https://review.openstack.org/#/c/37580/)
  • There is a new default policy.json file. Deployers with existing deployments should update their files as many options have changed: policy.json

Deprecation Notices

  • The usage of "quantum" or "Quantum" in configuration files and executable names is officially deprecated. This is the last release that will support those names and new deployments should use proper Neutron names for those values. Support for compatibility will only exist in this release.
  • The Linux Bridge and Open vSwitch plugins have been feature frozen and will be removed in the J (2014.2) release. New deployments should choose ML2 instead of the individual Open vSwitch or Linux Bridge plugins.

OpenStack Block Storage (Cinder)

主な新機能

  • ボリュームマイグレーション（異なる Cinder バックエンドにボリュームを移動させる為の管理者API）
  • V2 API にスケジューラヒント拡張追加
  • LVM 無しで直接ディスクを使えるようにする為のローカルブロックストレージドライバ追加
  • 既存ボリュームのサイズ拡張機能追加
  • あるテナントから別テナントへのボリューム転送機能追加
  • デフォルトクォータ設定の編集用API追加
  • スナップショットからボリュームを作る際に依存関係を排除する、バックエンド用のスナップショット自動展開用設定オプション追加
  • ボリュームアタッチ時、インスタンスUUIDに加えて「ホスト名」を指定可能にするAPI追加
  • バックアップレイヤを汎用化し、内部的な調整無しで任意の iSCSI デバイスからのバックアップを可能に
  • バックアップサービスに Ceph ドライバ追加（CephからCephへの差分バックアップ可能な、バックアップ先としてCephを選択可能）
  • QoS情報追加（Nova に情報が渡されて、ハイパーバイザによって使用される）
  • 新しい Windows ストレージサーバドライバ (blueprint)

新しいハードウェアベンダドライバ

  • Dell EqualLogic ドライバ
  • VMware VMDK ドライバ
  • IBM General Parallel File System (GPFS) ドライバ

既存ドライバの主要な強化点

  • Huawei ストレージシステム用ファイバチャネルドライバ追加
  • Nexenta ストレージ対応用 NFS ボリュームドライバ追加
  • ほぼ全てのベンダドライバに対する、各種アップデートとデバイスに特化した機能強化
  • IBM Stowize ドライバにボリュームマイグレーション用の調整実施

新しいバックアップドライバ

  • ボリュームバックアップ用 Ceph ドライバ
  • IBM Tivoli Storage Manager (TSM) ドライバ

既知の問題

  • Bug #1237338 : VMware ボリュームドライバでボリューム→イメージのアップロードが失敗する
  • Bug: #1240299 : 全ての LVM ボリュームにおけるボリュームのゼロクリア処理がシンプロビジョニングされた LVM まで消去する。修正がリリースされるまで、cinder.conf 中で volume_clear=None を設定する事。

アップグレード時の注意

  • ThinLVM ボリュームドライバの機能は、今回標準の LVM iSCSI ボリュームドライバの一部になりました。設定ファイル中の volume_driver="cinder.volume.drivers.lvm.LVMISCSIDriver" を lvm_type="thin" に変更する必要があります。後方互換性のため、Havana リリースでは、この変更は volume_driver が "cinder.volume.drivers.lvm.ThinLVMVolumeDriver" に設定されている場合は自動的に行われますが、Icehouse では cinder.conf 中でこれらのオプションを更新する必要があるでしょう。

OpenStack Metering (Ceilometer)

主な新機能

API

  • The statistics endpoint can now be used to group samples by some fields using the groupby argument
  • A new alarm API is now available (see Alarms)
  • Users can now post their own samples and meters through the API

Alarms

Alarms are a new feature allowing users and operators to trigger actions based on comparing the statistics trend against a threshold over a period of time. It is composed of the following services:

  • ceilometer-api now exposes the new /v2/alarms endpoint providing control over alarm lifecycle;
  • ceilometer-alarm-evaluator evaluates alarms periodically in order to detect detects when an alarm state changes;
  • ceilometer-alarm-notifier receives notifications sent by ceilometer-alarm-evaluator when an alarm is triggered and executes the associated action

The alarm API also exposes the history of alarm state transitions and rule changes.

Collector

  • New HBase driver
  • New DB2 (NoSQL) driver
  • Improved SQLAlchemy driver
  • Improved MongoDB driver
  • Added a TTL functionality that allows to delete old samples from the database
  • Added the ability to store events
  • Added event storage feature on SQLAlchemy

Publisher drivers

  • Added a UDP based publisher

Transformers

  • Added new unit-scaling and rate-of-change transformers

Meters

  • Added a meter on API requests using a special Python middleware
  • Added the ability to record samples from the new Neutron bandwidth metering feature

Compute agent

  • Added support for Hyper-V

既知の問題


OpenStack Orchestration (Heat)

主な新機能

Much improved documentation

Initial integration with Tempest

Concurrent resource operations

  • Non dependent create, update and delete operations are now performed in parallel

Much improved networking/Neutron support

  • New LBaaS, FWaaS and VPNaaS resources

Initial support for native template language (HOT)

Provider and Environment abstractions

  • Abstractions to provide a way to customize resource types using nested templates see documentation and blog post

Ceilometer integration for metrics/monitoring/alarms

  • Adds a new resource type OS::Ceilometer::Alarm which configures a ceilometer alarm
  • Also we have integration with Ceilometer alarms for AutoScaling actions, which are now triggered by Ceilometer alarms. The previous mechanism where metrics/alarms are processed by Heat still exists, but is now deprecated and will most likely be removed during Icehouse.

UpdateStack improvements

  • Several resource types now provide better support for non-destructive updates, including resizing an Instance. Also we now create replacement resources before deleting the previous resource, allowing better upgrade continuity and roll-back capability.

Initial integration with keystone trusts functionality

  • Initial integration with keystone trusts, so when heat.conf specifies deferred_auth_method=trusts, we no longer store encrypted credentials to perform deferred operations (for example AutoScaling adjustments), but instead create a trust and store the ID of the trust.
  • (下記の「既知の問題」を参照のこと)

Improved resource documentation

Many more native resource types

New Rackspace resource types

  • Rackspace::Cloud::DBInstance
  • Rackspace::Cloud::LoadBalancer
  • Rackspace::Cloud::Server

Stack suspend/resume

  • Support for a new API "actions" path, which enables stack suspend/resume

Consolidated configuration to a single heat.conf and a single paste-api.ini

  • 下記の「アップグレード時の注意」を参照してください。
  • Also added new config options to provide limitations on:
template size
number of stacks per tenant
number of events per stack
stack nesting depth

Heat Standalone Mode

  • Heat can now be configured to run in standalone mode, allowing it to orchestrate onto an external OpenStack

既知の問題

  • Heat does not support specifying region name when getting API endpoints from keystone see bug
  • Integration with keystone trusts (deferred_auth_method=trusts) will only work if you have the latest keystoneclient 0.4.1, however this is not reflected in the requirements.txt of Heat yet
https://bugs.launchpad.net/python-keystoneclient/+bug/1231483
  • Integration with keystone trusts requires at least RC3 of keystone due to this issue
https://bugs.launchpad.net/keystone/+bug/1239303

アップグレード時の注意

  • Heat now uses one config file (/etc/heat/heat.conf) instead of per-service files.
  • The API processes now use a single paste configuration file (/etc/heat/api-paste.ini) instead of per-service files.
  • There is now support for a global environment definition in /etc/heat/environment.d/ (see environment documentation)
  • All OS::Neutron* resources have been renamed "OS::Quantum*", the old names will still work if you install the provided default environment which aliases the old names to the new resources.

OpenStack ドキュメント

主な新機能

  • ドキュメントのバグを簡単に報告できるよう、各ページにバグ報告のリンクを作成しました。
  • マニュアルが完全に再構成されました。Havana リリースでは、以下のガイドがあります:
    • OpenStack のインストール
      • Installation Guide for Red Hat Enterprise Linux, CentOS, and Fedora
      • Installation Guide for Ubuntu 12.04 (LTS)
      • Installation Guide for openSUSE and SUSE Linux Enterprise Server
    • OpenStack クラウドの設定および運用
      • Cloud Administrator Guide
      • Configuration Reference
      • Operations Guide
      • High Availability Guide
      • Security Guide
      • Virtual Machine Image Guide
    • OpenStack dashboard およびコマンドラインクライアントの使用法
      • API Quick Start
      • End User Guide
      • Admin User Guide

既知の問題

  • いくつかのガイドが完全には更新されておらず、必要な情報が不足している可能性があります。

memo

  • nova : amotoki
  • cinder: yosshy
  • Keystone: katomo
  • horizon : thirai
  • glance: yosshy
Retrieved from "https://wiki.openstack.org/w/index.php?title=ReleaseNotes/Havana/ja&oldid=33092"