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

15.0.1

紹介

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

バグ修正

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

15.0.0

紹介

  • refactored image import 機能の Minimal Viable Product 配信のために導入された新しい呼び出しを含む API の実験的バージョンを導入するために、Images API v2 の*マイナー*バージョンは 2.6 に引き上げられました。バージョン 2.5 は Image API の現行バージョンのままです。

新機能

  • Image v2 API への image-list の呼び出しで、クエリーストリングのパラメータ protected が認識されるようになりました。このパラメータは、true または false の2つの値しか受け付けません。フィルターは大文字と小文字を区別します。他の値を指定すると、要求に対する応答が 400 になります。詳細は、protected filter specification ドキュメントを参照してください。

  • 新しいポリシー tasks_api_access が導入され、Tasks API をエンドユーザーに公開することなく、相互運用可能なイメージのインポートプロセスを行うタスクを管理するのに、一般的なユーザー認証情報を Glance が使用できます。

  • Glance is now packaged with a WSGI script entrypoint, enabling it to be run as a WSGI application hosted by a performant web server. See Running Glance in HTTPD in the Glance documentation for details.

    Glance を配備するこの方法にはいくつかの制限があり、現時点では本番環境での使用を推奨していません。詳細については、このドキュメントの`既知の問題`_セクションを参照してください。

既知の問題

  • Glance をウェブサーバーにホストされる WSGI アプリケーションとして稼働させるサポートが追加されましたが、Glance から提供される Image API の非定型的な性質により、大量のイメージデータを転送できるため、このアプローチは注意深く設定することなく動作させるのは困難です。Glance は、イメージアップロードをチャンク転送符号化の使用に依存しており、チャンク転送符号化のサポートは、WSGI 仕様 には要求されていません。

    Glance のドキュメンテーションの HTTPD で Glance を実行する セクションでは、Apache の httpd サーバで Glance を使用する(使用しない)方法の概要が記載されています。これは、Glance が devstack の WSGI アプリケーションとして設定される方法です。そのため、これは私たちが最も経験を積んだ方法です。別の Web サーバを使用して Glance を配備しようとする場合は、結果を Glance のドキュメントに投稿することを検討してくださいませ。

    現在、ドキュメントで推奨されているガイドラインに従って Glance が devstack で実行されるように設定されている場合、ゲートでいくつかの問題が発生しています。Bug 1703856 に従って詳細を知ることができます。

    Glance チームが判断する限り、Glance を WSGI アプリケーションとして稼働させる難しさは、Glance の外部の問題に起因します。よって、 Glance チームは、特に本番環境では、通常のスタンドアローンの設定で動作させることを推奨します。もし、Glance を WSGI アプリケーションとしてウェブサーバーで稼働することを選択した場合、現実的なユースケースシナリオとともに、注意深く、確実に構成をテストしてください。

アップグレード時の注意

  • Glance によって提供される Image API の**実験的**バージョンは、2.6 として紹介されています。これには、refactored image import 機能のために導入された新しい API 呼び出しが含まれています。この機能はデフォルトで有効になって**いません**ので、現行バージョンの Images API は 2.5 のままです。このリリースのバージョン 2.5 API には変更がないため、新しいインポート機能が有効かどうかに関わらず、バージョン 2.5 のすべての呼び出しが機能します。

    バージョン 2.6 API は、refactored image import 仕様で説明されている機能の Minimal Viable Product であるため、実験的に導入されています。MVP としては、その仕様に記述されている応答はバージョン 2.6 で省略されています。Queens でバージョン 2.6 が完成する想定であり、現時点では、オペレーターに新しい機能を試してみることを奨励しますが、実験的な性質を念頭に置いてください。

  • 廃止予定の値は、設定オプション store_type_preference では認識されなくなりました。二つの標準でない値 'filesystem' と 'vmware_datastore' は Newton で廃止予定となり、もはや動作不能です。それらのストアの正しい値は 'file' と 'vmware' です。 詳細については、Newton のリリースノート(https://docs.openstack.org/releasenotes/glance/newton.html#upgrade-notes)を参照してください。

  • OpenStack Artifacts サービス (Glare) のコードとその実験的 API は Glance のコードから`削除`_され、前のリリースサイクルで独立の Glare プロジェクトのリポジトリーに再配置されました。Glance の Pike リリースのデータベースアップグレードは、Glare テーブル('artifacts' および 'artifact_*')を Glance データベースから削除します。

    Glare を提供する OpenStack のデプロイメント、パッケージャー、およびデプロイメントプロジェクトは、Newton と Ocata のリリースの間に、Glare が 自身の Glare リポジトリから Glare を使い始めるはずでした。Pike リリースでは Glance リポジトリから Glare コードを使用することはもはや不可能です。

  • oslo.concurrency の lock_path 設定オプションは、sql image_cache ドライバーの使用に必要です。指定されていない場合は、デフォルトで image_cache_dir になり、警告が出力されます。

  • Pike リリースでは、以下のメタデータ定義が変更されています:

    • プロパティ img_hide_hypervisor_id が名前空間 OS::Compute::LibvirtImage に追加されました。

    • OS::Compute::VMware 名前空間の vmware_ostype プロパティにいくつかの`新しい値`が追加されました。

    これらの定義は、次の方法でアップグレードできます。

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

  • glance-api.conf ファイルの keystone_authtoken グループで timeout オプションを設定することができます。

  • 新しい相互運用可能なイメージのインポート機能を含む、実験的なバージョン 2.6 の API を有効にしたい場合、glance-api.conf ファイルで設定オプションの enable_image_import を True に設定してください。このオプションのデフォルト値は False です。

    相互運用可能なイメージのインポート機能は、Glance タスクエンジンを使用します。これは、相互運用可能なイメージインポートワークフローのために Tasks API を使用*しない*ため、エンドユーザーにとって透過的です。ただし、オペレーターは次の設定オプションが正しく設定されていることを確認する必要があります。

    • enable_image_import

    • node_staging_uri

    • [task] グループのオプション

    • [taskflow_executor] グループのオプション

    詳細については、glance-api.conf ファイルのサンプルを参照してください。

    さらに、Glance の policy.json ファイルにあるタスクに関連するポリシーが正しく設定されていることを確認する必要があります。これらの設定は、以下に記述されています。

  • 新しいポリシー tasks_api_access が導入され、Tasks API をエンドユーザーに公開することなく、相互運用可能なイメージのインポートプロセスを行うタスクを管理するのに、一般的なユーザー認証情報を Glance が使用できます。

    Tasks API は、Mitaka では、以下のポリシーターゲットを role:admin に制限することによってデフォルトで管理者のみになっていました: get_taskget_tasksadd_taskmodify_task

    新しい tasks_api_access ポリシーターゲットは Tasks API へのアクセスを直接制御しますが、ターゲットは Glance の内部タスクオブジェクトに対して実行できる操作を制御することで、API 経由で操作できるものに間接的に影響します。要点は、Tasks API を管理者専用にしつつ、新しい相互運用可能なイメージのインポートプロセスをエンドユーザーに公開したい場合は、次の設定を使用してこれを実現できます。

    "get_task": "",
    "get_tasks": "",
    "add_task": "",
    "modify_task": "",
    "tasks_api_access": "role:admin",
    

    要約すると、エンドユーザーは、新しい相互運用可能なイメージインポートプロセスを使用するために Tasks API にアクセスする必要は**ありません**。ただし、内部の Glance タスクオブジェクトにアクセスする権限が必要です。

    実験的なバージョン 2.6 API を公開するかどうかの決定とは関係なく、すべてのオペレータがこのポリシー設定を採用することを推奨します。

セキュリティー上の問題

  • 新しいポリシー tasks_api_access が導入され、Tasks API をエンドユーザーに公開することなく、相互運用可能なイメージのインポートプロセスを行うタスクを管理するのに、一般的なユーザー認証情報を Glance が使用できます。

    Glance の policy.json ファイルを見直して default ターゲットが含まれているかどうか確認する良い機会です。ルールはかなり制限されています ( "role:admin" や "!" は良い選択です)。default ターゲットは、ポリシーエンジンが探しているターゲットを見つけることができない場合に使用されます。これは、新しいポリシーが導入されたが、使用中のポリシーファイルが以前のリリースのものである場合に発生する可能性があります。

バグ修正

  • Ocata リリースで導入された**実験的**ゼロ・ダウンタイム・データベース・アップグレード・パスにバグがあり、**実験的な**アップグレードが機能ませんでした。これは Pike リリースで修正されています。このバグは、通常のデータベースのアップグレード操作には影響しませんでした。

  • 以下は、このリリースに含まれるバグ修正のハイライトの一部です。

    • Bug 1655727: eventlet 0.20.1 に十分間に合う monkey_patching 呼び出し

    • Bug 1657459: WebOb 1.7 との非互換性の修正

    • Bug 1554412: FK の失敗に対する、ユーザーフレンドリーなメッセージの提供

    • Bug 1664709: キャッシュから部分イメージダウンロードリクエストを提供しない

    • Bug 1482129: 辞書から重複したキーを削除する

    • Bug 1229823: イメージキャッシュのファイル削除競合を処理する

    • Bug 1686488: glance image-download エラーの修正

    • Bug 1516706: v1_api から v2_registry へのリクエスト作成の防止

    • Bug 1701346: 信頼認証メカニズムの修正

  • Glance は、RFC 7233 に反して GET v2/images/{image_id}/file リクエストで Content-Range ヘッダーを受け付けていました。Glance は RFC 7233 に追随するようになり:

    • 部分イメージを提供するリクエストで Range ヘッダーを受け付けます。

    • 要求された部分コンテンツの配信が成功すると、Content-Range ヘッダーを含めます。

    すべての Glance ストレージバックエンドが部分的なダウンロードをサポートするわけではないことに注意してください。そのようなバックエンドを持つ GlanceサーバーへのRange リクエストは、206 レスポンスコードにもかかわらず、イメージコンテンツ全体が配信される結果になります。

  • ジョブフェッチエラーの場合のスクラバーの動作の変更に注意してください:

    • デーモンモードで動作するように設定した場合、Scrubber はクリティカルレベルでエラーメッセージを出力しますが、プロセスを終了しません。

    • 非デーモンモードで動作するように設定した場合、Scrubber はクリティカルレベルでエラーメッセージを出力し、ステータス 1 で終了します。

その他の注意点

  • OpenStack Artifacts サービス (Glare) のコードとその実験的 API は Glance のコードから`削除`_されました。

    Artifacts API は、Liberty リリースでは Glance サービスエンドポイント上で /v3 として実行された実験的な API でした。Mitaka リリースでは、Glance /v3 の実験的 API は廃止予定となり、Artifacts サービスは v0.1 としてバージョン付された実験的 API として独自のエンドポイント(Glance サービスエンドポイントから完全に独立)で動作しました。Liberty と Mitaka リリースの両方では、Glare は Glance コードリポジトリに格納されたコードを実行し、Glance データベースに独自のテーブルを使用しました。

    Newton リリースでは、Glare コードが独自の Glare プロジェクトリポジトリに再配置されました。また、Newton リリースでは、Glare は独自のエンドポイントで v1.0 としてバージョン付けされた実験的な Artifacts API を実行し、独自のデータベースを使用しています。

    For the Pike release, the legacy Glare code has been removed from the Glance code repository and the legacy 'artifacts' and 'artifact_*' database tables are dropped from the Glance database. As the Artifacts service API was an EXPERIMENTAL API in Glance and has not used the Glance database since Mitaka, no provision is made for migrating data from the Glance database to the Glare database.

  • 現在の OpenStack ポリシーに従い、Glance のログメッセージは、`もう翻訳されていません `_。

  • イメージサービス API リファレンスは、`相互運用可能なイメージのインポート`_プロセス(「イメージインポートリファクタリング」とも呼ばれる)セクションで更新され、その API 呼び出しが実験的な API v2.6 で実装するために公開されました。