Ocata バージョンのリリースノート

14.0.1

紹介

このポイントリリースには、現在のオペレーティングシステムパッケージを尊重する、Glance の Ocata リリースを安定に保つための小さな変更が含まれています。

バグ修正

• Python 2.7 配布パッケージの変更により、Glance での eventlet の使用が影響を受けました。その結果、チームは eventlet 0.22.0から Glance のコードに修正をバックポートしました。OpenStack の Ocata リリースでは、eventlet 0.19.0 が使用されています。詳細は、Bug 1747305 を参照してください。

その他の注意点

• 翻訳が更新されました。

14.0.0

紹介

• サポートされるディスク形式の一覧に ploop を追加しました。

• 実験的 expand-migrate-contract の一連の操作を使用した停止時間なしのデータベースアップグレードが利用可能です。

• Images API v2 の*マイナー*バージョンは ** 2.5 ** に引き上げられました。

• *コミュニティイメージ*機能が Images API v2 に導入されました。これにより、ユーザーは他のすべてのユーザーがイメージを利用できるようにすることができます。この変更に伴い、イメージの「可視性」値が「community」と「shared」を含むように拡大されました。

イメージの場所の更新は、active または queued ステータスのイメージに限定されます。詳細については、「バグ修正」セクションを参照してください。

新機能

• Glance のサポートされているディスクフォーマットのリストに識別子 ploop が追加されました。それぞれの設定オプションが更新され、デフォルトのリストはサポートされている形式として ploop を表示します。

• イメージの「可視性」を変更しました。

  • Ocata 以前は、'private' 可視性を持つイメージは、その可視性が 'private' であったにもかかわらず、それにメンバーを追加することによって共有することができました。Ocata では、イメージの可視性をより明確にするために、以下の変更が導入されています:

    • 可視性の新しい値 'shared' が導入されました。所有、あるいはメンバーがアクセスできるイメージは、可視性 'private' としては表示されず、エンドユーザーとの間での混乱を減少します。

    • メンバーを許諾するには、イメージは shared 可視性を持つ必要があります。これは、'private' イメージが誤って共有されてしまうことから保護します。

    • 現在の共有ワークフローとの後方互換性を維持するために、Ocata のイメージのデフォルトの可視性は「shared」になっています。Ocata 以前の動作と一貫して、イメージの可視性を最初に更新することなく、イメージのメンバー操作を受け入れることができます。 （「shared」の可視性を持つがメンバーを持たないイメージは、イメージ所有者以外の誰も実際にアクセスできないため、セキュリティ上の問題はありません。）

• イメージの可視性は、イメージ作成の時に指定できます。

  • 前述のように、イメージのデフォルトの可視性は 'shared' です。ユーザーがイメージをプライベートにしてメンバーを受け入れたくない場合は、作成時に 'private' の可視性を明示的に割り当てることができます。

    • そのようなイメージは、メンバーを受け入れる前に、その可視性を 'shared' に更新する必要があります。

• イメージの可視性は、イメージ変更 (PATCH) 呼び出しを使用して変更されます。

  • 注: これは変更ではありません。完全性のために単純に別記しているだけです。

• イメージの 'visibility' フィールドに、新しい値 'community' が導入されました。

  • 'community' 可視性を持つイメージは、すべてのユーザーが利用できます。

  • ユーザーが他のユーザーの image-list 応答をスパムすることを防止するために、コミュニティイメージは、ユーザによって特に要求されない限り、image-list 応答に含まれません。

    • 例えば、 GET v2/images?visibility=community

    • image-list の通常の動作として、リクエストに他のフィルターが適用される可能性があります。例えば、931efe8a-0ad7-4610-9116-c199f8807cda のユーザーから提供されたコミュニティのイメージを参照するために、次のようなリクエストが作成されます: GET v2/images?visibility=community&owner=931efe8a-0ad7-4610-9116-c199f8807cda

アップグレード時の注意

• disk_format 設定オプションは、デフォルトでサポートされている ploop を有効にします。

• Glance がデータベースのアップグレードに使用したデータベース移行エンジンが、このリリースの SQLAlchemy Migrate から Alembic に変更されました。

  • これにより、移行スクリプトの場所と命名規則の変更が必要になりました。開発者、オペレーター、および DevOps は、Ocata リリースで導入された変更の詳細について、Glance のドキュメントの Database Management セクションを読むことを強くお勧めします。変更の概要は次のとおりです。

    • すべての glance manage db コマンドは、version、upgrade、sync、``version_control``などの操作を行うために、Alembicを使うよう適切に変更されました。したがって、旧式の移行スクリプトは、Ocata 版の glance manage db コマンドでは動作しません。

    • データベースバージョンは数値ではなくなりました。データベースに適用された最後のマイグレーションの*リビジョン ID* になります。

      • 例えば、古いシステムでバージョン 42 のLiberty のマイグレーションは、liberty として表示されます。43 および 44 の Mitaka のマイグレーションは、それぞれ mitaka01 および mitaka02 として表示されます。

  • Glance のローリングアップグレード (Pike リリース予定) の実装の一環であるゼロダウンタイムデータベースのアップグレードを可能にするために、移行エンジンの変更が行われました。

    • このリリースでは、停止時間なしのデータベースアップグレードのプレビューが利用可能ですが、これは**実験的**で**本番環境ではサポートされません**。詳細は、Glance ドキュメンテーションの`データベース管理`_ セクションを参照してください。

• Glance によって提供されるバージョン 2 Images API の**現行**バージョンは ** 2.5 ** です。 変更点は次のとおりです。

  • 'visibility' 列挙子は、2 つの値 (public と private) から 4 つの値 (public、private、shared、および community) に増加しました。

  • 以前は、private 可視性のイメージにメンバーを追加でき、それによって「共有」イメージを作成できました。このリリースでは、メンバーの操作を受け付けるには、イメージは shared 可視性を持つ必要があります。private 可視性を持つイメージにメンバーを追加しようとすると、有用なメッセージを含む 4xx response が返されます。

• いくつかのバックエンドストアー名は glance と glance_store の間で矛盾していました。これは、VMware データストアー、あるいはファイルシステムストアーのオペレーターが、glance_store で有効な識別子に対応していないストアー名を glance-api.conf に使用する必要があることを意味していました。このような状況が誤った設定とオペレータの不幸を助長したため、Newton リリースではストアー名が一貫するようにしました。これの意味するところは:

  • この変更は、複数のイメージロケーションを使用するオペレータにのみ適用されます。

  • この変更は、VMware データストアーまたはファイルシステムストアーを使用するオペレータにのみ適用されます。

  • この変更は store_type_preference オプションにのみ適用されます。

  • VMware データストアオペレーター: 現在**廃止予定**の古い名前は、vmware_datastore でした。glance と glance_store の両方で使用される**新しい**名前は、 vmware です。

  • ファイルシステムストアオペレーター: 現在**廃止予定**の古い名前は、filesystem でした。glance と glance_store の両方で使用される**新しい**名前は、 file です。

  • この変更は下位互換性のため、つまり、廃止予定期間では古い名前がコードによって認識されます。廃止予定の名前のサポートは Pike リリースで削除されます。

  • 我々は、オペレータが glance-api.conf ファイルを直ちに修正して**新しい**名前を使用することを強く推奨します。

• イメージの 'visibility' フィールドに、新しい値 'community' が導入されました。

  • イメージを更新して 'community' 可視性を持たせる機能は、'communitize_image' という名前のポリシーターゲットによって管理されます。デフォルトは空です。つまり、どのユーザーもイメージを共有できます。

• 現在のイメージの可視性の移行

  • Ocata 以前は、Glance データベースには 'visibility' の列はありませんでしたが、代わりに ブール値の 'is_public' 列が使用されていました。この列は Images API v2 のイメージレスポンスで 'public' または 'private' 可視性に変換されていました。Ocata へのアップグレードの一環として、'visibility' 列が images テーブルに導入されています。これには、次のように入力されます

    • 可視性 'public' (データベース上で 'is_public' が True のイメージ) を持つすべてのイメージは、可視性を 'public' に設定されます。

    • 可視性 'private' (データベース上で 'is_public' が False のイメージ) を持つ、**かつ**イメージのメンバーを持つ、すべてのイメージは、可視性を 'shared' に設定されます。

    • 'private' 可視性を持ち (つまり、'is_public' がデータベースで False であるイメージ) 、かつイメージメンバーが**いない**イメージは、可視性が 'private' に設定されます。

      • そのようなイメージは、メンバーを受け入れる前に、その可視性が 'shared' に更新されなければならないことに注意してください。

• Ocata の可視性の変更による、Images API v2 のエンドユーザーへの影響

  • 私たちはエンドユーザーへの影響を最小限に抑えようとしましたが、認識すべきいくつかの問題を示したいと思います。

    • イメージの可視性の移行は、アップグレード時に妥当な値をイメージに割り当てます。すなわち、エンドユーザーがメンバーを割り当てて*いない*イメージに 'private' を割り当て、メンバーを持つイメージに 'shared' を割り当てます。 以前は、エンドユーザーがプライベートのイメージを共有したい場合、メンバーを直接追加することができました。アップグレード後は、メンバーシップを割り当てる前に、イメージの可視性を 'shared' に変更する必要があります。

    • デフォルト値の 'shared' は奇妙に見えるかもしれませんが、(1) デフォルトの可視性を持つイメージを作成し、(2) そのイメージにメンバーを追加する、というアップグレード前のワークフローを補助します。さらに、可視性が 'shared' で、メンバーを持たないイメージには他のユーザーからアクセスできないため、機能的には非公開イメージです。

    • イメージ作成操作では、イメージ作成時に可視性を設定することができます。以前は 2 つの可視性しか利用できなかったことを考えると、このオプションはおそらくあまり使われていないでしょう。そのうちの 1 つ ('public') は、デフォルトではエンドユーザーによって割り当て解除できません。オペレーターは、エンドユーザーがイメージを作成する際に、ドキュメントやツールを更新して可視性の値を指定したい場合があります。 要約すると:

      • 'public' - すべてのユーザーにオペレーターから提供されるイメージで、デフォルトで設定されます。

      • 'private' - 所有者だけがイメージにアクセスできます。

      • 'community' - すべてのユーザーがイメージを利用できます。

      • 'shared' - 所有者は完全なアクセス権を持ち、メンバーが利用可能なイメージです。

• Ocata の可視性の変更による、Images API v1 への影響

  • 廃止予定となった Images API v1 は、「可視性」のコンセプトを持っておらず、v1 のみの構成では、何が変更されたか気づくことができません。しかし、このような状況にならないことを願い、もし混在環境で Image API v1 を使用した場合に想定されることを次に記します。

    • v1 APIでは、イメージは is_public フィールドを持ちます（ただし、visibility フィールドはありません）。is_public が True のイメージは、v2 API の 'public' 可視性を持つイメージと同等です。is_public が False の画像は、メンバーがある場合は v2 の 'shared' イメージに相当し、メンバーがない場合は v2 の 'private' イメージに相当します。

    • v2 APIで 'community' 可視性を持つイメージは、v1 API で is_public == False になります。 プライベートイメージのように振る舞います。つまり、所有者（または管理者）だけがイメージにアクセスでき、所有者（または管理者）だけが image-list 応答でイメージを表示できます。

    • イメージ作成時の「可視性」のデフォルト値は 'shared' なので、v1 API を使用して新しく作成されたイメージは、Ocata 以前と同じように、メンバーを追加できます。

    • v2 API で参照するときに、イメージが 'private' の可視性を持つ場合、v1 API ではそのイメージはメンバーを受け入れません。ユーザーがそのようなイメージを共有したい場合は、下記のようにすることができます:

      • v2 API を使用して、イメージの可視性を 'shared' に変更します。その後、v1 または v2 API でメンバーを受け入れます。

      • v1 API を使用してイメージを更新し、is_public が False になるようにします。これにより、イメージの可視性が 'shared' にリセットされ、メンバー操作を受け入れるようになります。

      • v2 API で 'private' 可視性を持つイメージを扱う場合、ユーザーが意図せずにイメージにメンバーを追加してデータを公開することに対する安全策があることに注意してください。 安全策は、他のユーザーに公開する前に、v1 または v2 API のどちらでも、イメージ更新操作を追加で実行する必要があることです。

• A recent change to oslo.log (>= 3.17.0) set the default value of [DEFAULT]/use_stderr to False in order to prevent duplication of logs (as reported in bug #1588051). Since this would change the current behaviour of certain glance commands (e.g., glance-replicator, glance-cache-manage, etc.), we chose to override the default value of use_stderr to True in those commands. We also chose not to override that value in any Glance service (e.g., glance-api, glance-registry) so that duplicate logs are not created by those services. Operators that have a usecase that relies on logs being reported on standard error may set [DEFAULT]/use_stderr = True in the appropriate service's configuration file upon deployment.

• OS :: Compute :: Hypervisor 名前空間の hypervisor_type のメタデータ定義は、vz として指定された Virtuozzo ハイパーバイザーを含むように拡張されました。次のように定義をアップグレードすることができます。

  glance-manage db load_metadefs [--path <path>] [--merge] [--prefer_new]

セキュリティー上の問題

• すべての qemu-img info 呼び出しは、コマンドを実行するプロセスの CPU 時間とアドレス空間使用量を、それぞれ2 秒および 1GB に制限されたリソース制限の下で実行されます。これは、バグ https://bugs.launchpad.net/glance/+bug/1449062 に対応しています。"qemu-img" の現在の使用は、Glance のタスクに限定されおり、(Mitaka リリース以降) デフォルトでは、管理者ユーザーのみが利用できます。タスクは信用できるユーザーのみに公開することを引き続き推奨します。

バグ修正

• active または queued ステータスではないイメージの場所の変更は、競合状態やセキュリティ問題、ユーザーやオペレーターに対する不利益をもたらす可能性があります。よって、イメージの場所の更新は、このリリースで制限されます。ユーザーは以下をのことに遭遇するかもしれません:

  • イメージの状態が active にない場合、イメージの場所の置き換えをしようとすると、HTTP Response Code 409 (Conflict) が返されます。

  • イメージの状態が active あるいは queued にない場合、イメージの場所の置き換えをしようとすると、HTTP Response Code 409 (Conflict) が返されます。

その他の注意点

• 設定オプション show_multiple_locations の廃止予定のパスは、OSSN-0065 の緩和指示がこのオプションを参照するため変更されました。Pike リリース以降に削除される可能性があります。このオプションのヘルプテキストは、それに応じて更新されました。