第4章 テクニカルノート

本項に記載するバグは、アドバイザリー RHEA-2018:2086 で対応しています。このアドバイザリーについての詳しい情報は、RHEA-2018:2086 - Product Enhancement Advisory を参照してください。

ceph-ansible

ceph-ansible ユーティリティーは、ceph-create-keys コンテナーが作成されたのと同じノードから ceph-create-keys コンテナーを必ずしも削除しません。

このため、Error response from daemon: No such container: ceph-create-keys.というメッセージが表示されてデプロイメントが失敗する場合があります。 この失敗が、ceph-ansible の実行に影響を及ぼす場合があります。これには、複数のコンピュートノードを使用している、または Ceph クライアントとして動作し Ceph を使用するサービスをホスティングするカスタムロールを使用している新規デプロイメントが含まれます。

gnocchi

openstack-gnocchi パッケージは gnocchi という名前に変更されました。アップストリームのスコープが変更されたため、openstack- の接頭辞は削除されました。Gnocchi は OpenStack の傘下から外れて、スタンドアロンのプロジェクトになりました。

opendaylight

Floating IP をインスタンスに割り当ててからその Floating IP の割り当てを解除する際に、外部の IP への接続が失敗します。この状況は、次のような場合にテナントの VLAN ネットワークで発生します。NAPT 以外のスイッチ上で起動する仮想マシンに Floating IP が割り当てられた。その後にその Floating IP が削除された。これによって、NAPT スイッチの FIB テーブルでフローが (散発的に) 失われます。

失われた FIB テーブルのエントリーが原因で、仮想マシンはパブリックネットワークへの接続を失います。

Floating IP を仮想マシンに割り当てると、パブリックネットワークへの接続が復元されます。その Floating IP が仮想マシンに割り当てられている限りは、インターネットへの接続が可能です。ただし、外部ネットワークからのパブリック IP/Floating IP を失います。

openstack-cinder

以前のリリースでは、ローリングアップグレードのメカニズムが原因で、オフラインのアップグレードを実行する際に cinder サービスを 2 回再起動する必要がありました。

今回のリリースでは、新しいオプションのパラメーター--bump-versions を cinder-manage db sync コマンドに追加すると、2 回のシステム再起動はスキップすることができます。

Block Storage service (cinder) は同期ロックを使用してボリュームイメージキャッシュ内のエントリーが重複するのを防ぎます。このロックのスコープは広範過ぎていたため、イメージキャッシュが有効化されていない場合でも、イメージからのボリューム作成の要求が同時に発生すると、それらはロックをめぐって競っていました。

イメージキャッシュが有効化されていない場合のイメージからのボリューム作成の同時要求は、並行して実行するのではなくシリアル化する方が賢明です。

そのため、同期ロックは更新されてロックのスコープは最小限となり、ボリュームイメージキャッシュが有効化されている場合にのみ機能が有効となるようになりました。

今回のリリースでは、イメージからのボリューム作成の同時要求は、ボリュームイメージキャッシュが無効化されている場合には並行して実行されます。ボリュームイメージキャッシュが有効化されている場合には、キャッシュにはエントリーが 1 つしか作成されないようにするロックは最小限に抑えられるようになりました。

openstack-manila

Shared File System サービス (manila) は、IPv6 環境で manila を使用できるようにする NetApp ONTAP cDOT ドライバーを使用して IPv6 アクセスルールのサポートを提供するようになりました。

その結果、Shared File System サービスは、NetApp IPv6 ネットワーク上で ONTAP バックエンドによってバッキングされる共有のエクスポートをサポートします。エクスポートされた共有へのアクセスは、IPv6 クライアントのアドレスによって制御されます。

Shared File System サービス (manila) は、NFSv4 プロトコルを使用した、Ceph File System (CephFS) によってバッキングされる共有ファイルシステムのマウントをサポートしています。コントローラーノード上で稼働する NFS-Ganesha サーバーを使用して、高可用性 (HA) を使用するテナントに CephFS をエクスポートします。テナントは相互に分離され、提供される NFS ゲートウェイインターフェイスを介してのみ CephFS にアクセスすることができます。この新機能は director に完全に統合され、CephFS バックエンドのデプロイと Shared File System サービスの設定が可能です。

openstack-neutron

ルーターにインターフェイスが追加または削除されて DHCP エージェントで分離されたメタデータが有効化となった際に、そのネットワークのメタデータプロキシーが更新されません。

そのため、インスタンスがルーターに接続されていないネットワーク上にある場合には、そのインスタンスはメタデータをフェッチできません。

ルーターのインターフェイスの追加/削除時には、メタデータプロキシーを更新する必要があります。それにより、インスタンスは、使用しているネットワークが分離された場合に DHCP 名前空間からメタデータをフェッチすることができるようになります。

openstack-selinux

以前のリリースでは、ゲスト仮想マシンの起動時に、virtlogd サービスがログ記録する AVC 拒否のエラーが重複していました。今回の更新で、virtlogd サービスはシャットダウンを抑制するコールを systemd に送信しなくなり、このエラーが発生しなくなりました。

openstack-swift

Object Store サービス (swift) は Barbican を統合して、保管されている (at-rest) オブジェクトを透過的に暗号化/復号化できるようになりました。at-rest 暗号化は、in-transit 暗号化とは異なり、ディスクに保管されている間にオブジェクトが暗号化されることを指します。

Swift のオブジェクトは、ディスク上にクリアテキストとして保管されます。このようなディスクは、ライフサイクル終了に達した時に適切に破棄しなければ、セキュリティーリスクをもたらす可能性があります。このリスクは、オブジェクトを暗号化することによって軽減されます。

Swift はこれらの暗号化タスクを透過的に実行し、オブジェクトは swift にアップロードされる際には自動的に暗号化され、ユーザーに提供される際には自動的に復号化されます。この暗号化と復号化は、Barbican に保管されている同じ (対称) キーを使用して処理されます。

openstack-tripleo-common

Octavia は、service プロジェクトに設定されているデフォルトのクォータによりオーバークラウドで作成可能な Octavia ロードバランサーの数が限定されているため、実用的なワークロードにはスケーリングしません。

この問題を回避するには、オーバークラウドの admin ユーザーとして、必要なクォータを無制限または十分に大きな値に設定します。アンダークラウドで、以下の例に示すコマンドを実行します。

# source ~/overcloudrc
# openstack quota set --cores -1 --ram -1 --ports -1 --instances -1 --secgroups -1 service

tripleo.plan_management.v1.update_roles ワークフローは、トリガーするサブワークフローに対して、オーバークラウドのプラン名 (swift コンテナー名) または zaqar キュー名を渡しませんでした。これにより、デフォルト (overcloud) 以外のオーバークラウドプラン名を使用する場合に誤った動作が発生していました。今回の修正により、それらのパラメーターが正しく渡されるようになり、正しい動作に戻りました。

コンテナーが自動的に再起動するように設定されている場合、docker kill コマンドは終了しません。ユーザーが docker kill <container>の実行を試みると、無期限にハングする場合があります。そのような場合には、CTRL+C でコマンドを停止してください。

この問題を回避するには、(docker kill の代わりに)docker stop を実行して、コンテナー化されたサービスを停止してください。

原因:openstack overcloud node configure コマンドは、deploy-kernel および deploy-ramdisk のパラメーターにイメージ名だけを取り、イメージ ID は指定できませんでした。今回の修正後にイメージ ID が受け入れられるようになりました。

openstack-tripleo-heat-templates

今回の機能拡張により、director から通常のコンピュートノードとともに、RT 対応のコンピュートノードをデプロイする操作がサポートされるようになりました。

glance-direct メソッドには、HA 設定で使用する場合の共通のステージングエリアが必要です。共通のステージングエリアがない場合には、HA 環境で glance-direct メソッドを使用したイメージのアップロードが失敗する可能性があります。コントローラーノードで受信する要求は、利用可能なコントローラーノード間で分散されます。1 つのコントローラーが最初のステップを処理し、別のコントローラーが 2 番目の要求を処理し、両コントローラーは異なるステージングエリアにイメージを書き込みます。2 番目のコントローラーは最初のステップを処理するコントローラーが使用するのと同じステージングエリアにはアクセスできません。

Glance は、glance-direct メソッドを含む複数のイメージインポートメソッドをサポートしています。このメソッドは、3 段階方式を採用しており、イメージレコードを作成し、ステージエリアにイメージをアップロードしてから、ステージエリアからストレージバックエンドにイメージを移動して利用できるようにするステップで設定されます。HA の設定の場合は (コントローラー 3 台を使用)、glance-direct メソッドでは、全コントローラーノードにまたがった共有ファイルシステムを使用する共通のステージングエリアが必要です。

有効化する Glance インポートメソッドの一覧を設定できるようになりました。デフォルトの設定では、glance-direct メソッドは有効化されません (Web ダウンロードはデフォルトで有効化)。問題を回避して、HA 環境でイメージを Glance に確実にインポートできるようにするには、glance-direct メソッドは有効化しないでください。

openvswitch systemd スクリプトをホストで停止すると、/run/openvswitch フォルダーが削除されます。ovn-controller コンテナー内の /run/openvswitch パスは、古いディレクトリーになります。サービスが再度起動されると、新しいフォルダーが再び作成されます。ovn-controller がこのフォルダーに再度アクセスするには、そのフォルダーを再マウントするか、ovn-controller コンテナーを再起動する必要があります。

Cinder 用の RBD バックエンドで使用する Ceph プールの一覧を指定する新しい CinderRbdExtraPools Heat パラメーターが追加されました。一覧内の各プール用に追加の Cinder RBD バックエンドドライバーが作成されます。これは、CinderRbdPoolName に関連付けられた標準の RBD バックエンドドライバーに追加されます。新しいパラメーターは任意で、デフォルトでは空の一覧となります。すべてのプールが単一の Ceph クラスターに関連付けられます。

Redis は、TLS を有効化した HA デプロイメントでは、ノード間でデータのレプリケーションを正しく行うことができません。Redis のフォロワーノードにはリーダーノードからのデータは全く含まれません。Redis デプロイメントには TLS を無効にすることを推奨します。

今回の機能拡張により、Gnocchi DB インスタンスへのメトリックデータ送信がサポートされるようになりました。

collectd コンポーザブルサービス向けに以下の新しいパラメーターが追加されました。CollectdGnocchiAuthMode が simple に設定されると、CollectdGnocchiProtocol、CollectdGnocchiServer、CollectdGnocchiPort、CollectdGnocchiUser が設定に取り入れられます。

CollectdGnocchiAuthMode が keystone に設定されている場合には、CollectdGnocchiKeystone* パラメーターが設定に取り入れられます。

追加されたパラメーターに関する詳しい説明は以下のとおりです。

OVN メタデータサービスは、DVR ベースの環境ではデプロイされませんでした。そのため、インスタンスは、メタデータ (例: インスタンス名、公開鍵など) をフェッチできませんでした。

本リリースで提供されているパッチにより、このサービスは有効になり、ブートしたインスタンスはメタデータをフェッチすることができるようになりました。

Cinder バックエンドサービス用の Heat テンプレートは、サービスがコンテナーにデプロイされるべきかどうかには拘らず、Puppet をトリガーして cinder-volume サービスをオーバークラウドホストにデプロイしていました。そのため、cinder-volume サービスはコンテナー内とホスト上に 2 回デプロイされていました。

これが原因で、OpenStack ボリュームの操作 (ボリュームの作成と接続) がホスト上で実行される正当ではない cinder-volume サービスによって処理される場合、その操作は失敗することがありました。

そのため、Cinder バックエンドの heat テンプレートは cinder-volume サービスの 2 番目のインスタンスはデプロイしないように更新されました。

パフォーマンスの低い Swift クラスターが Gnocchi のバックエンドとして使用されると、collectd ログに 503 エラーと、gnocchi-metricd.conf に "ConnectionError: ('Connection aborted.', CannotSendRequest())" エラーが出力される場合があります。この問題を軽減するには、CollectdDefaultPollingInterval パラメーターの値を増やすか、Swift クラスターのパフォーマンスを改善してください。

ceph-ansible の複合 ceph-keys 処理により、/etc/ceph/ceph.client.manila.keyring ファイルの内容が誤って生成されるため、manila-share サービスの初期化が失敗します。

manila-share サービスを初期化できるようにするには、1) オーバークラウドのデプロイに使用する /usr/share/openstack/tripleo-heat-templates のコピーを作成します。

2) …​/tripleo-heat-templates/docker/services/ceph-ansible/ceph-base.yaml ファイルを編集して、295 行目の 3 つ並んだバックスラッシュをすべて 1 つのバックスラッシュに変更します。編集前: mon_cap: 'allow r, allow command \\\"auth del\\\", allow command \\\"auth caps\\\", allow command \\\"auth get\\\", allow command \\\"auth get-or-create\\\"' 編集後: mon_cap: 'allow r, allow command \"auth del\", allow command \"auth caps\", allow command \"auth get\", allow command \"auth get-or-create\"'

3) tripleo-heat-templates のコピーのパスを元の overcloud-deploy コマンドで実行した /usr/share/openstack-tripleo-heat テンプレートの場所に置き換えて、オーバークラウドをデプロイします。

ceph キーの /etc/ceph/ceph.client.manila.keyring ファイルには適切な内容が記載されるようになり、manila-share サービスは正常に初期化されるようになります。

cinder-volume サービスを HA 用に設定する場合には、cinder の DEFAULT/host 設定は hostgroup に設定されていました。他の cinder サービス (cinder-api、cinder-scheduler、cinder-backup) は、そのサービスを実行しているのがどのオーバークラウドノードであるかに拘らず hostgroup をそれらの設定に使っていました。これらのサービスのログメッセージはすべて同じ hostgroup ホストから送られたように表示されていたため、どのノードがメッセージを生成したかを判断するのが困難でした。

HA をデプロイする際には、DEFAULT/host がその値に設定されるのではなく、cinder-volume の backend_host が hostgroup に設定されます。これにより、各ノードの DEFAULT/host 値が一意となります。

その結果、cinder-api、cinder-scheduler、cinder-backup からのログメッセージはそのメッセージを生成したノードに正しく関連付けられます。

以前は、新しいリリースにアップグレードした後も、Block Storage サービス (cinder) は前のリリースの古い RPC バージョンを使用している状態のままとなっていました。このため、最新の RPC バージョンを必要とする cinder API の要求はすべて失敗していました。

新しいリリースにアップグレードすると、cinder RPC バージョンはすべて最新リリースと一致するように更新されるようになりました。

python-cryptography

python-cryptography は、バージョン 2.1 より、証明書で使用されている CNS 名が IDN 標準に準拠していることを確認するようになりました。検出された名前がこの仕様に従っていない場合には、cryptography はその証明書の検証に失敗し、OpenStack コマンドラインインターフェイスを使用する際や OpenStack のサービスログで異なるエラーが見つかる場合があります。

python-cryptography ビルドをインストールした後に、RDO からの最初のインポートは失敗していました。これは、Obsoletes が不足していたためです。また、このパッケージの RHEL 7 ビルドは正しく、適切な Obsoletes エントリーが含まれていました。

今回の修正で python-cryptography に Obsoletes が追加されました。

python-ironic-tests-tempest

アップグレードの前にインストールされる tempest のプラグイン (-tests) rpm は、OSP リリース 13 のアップグレードの後に失敗します。初回のアップグレードパッケージには古い RPM を廃止処理するために必要な epoch コマンドが含まれていませんでした。OSP 13 ではサブ rpm は提供されず、新しいプラグイン rpm 内の Obsoletes は正しい rpm を適切に廃止処理しませんでした。

この問題を修正するには、Obsolates を修正するか、古い rpm を手動でアンインストールして、代わりとなるプラグイン python2-*-tests-tempest を手動でインストールしてください。

python-networking-ovn

neutron と OVN のデータベース間の一貫性を維持するために、設定変更は内部で比較され、バックエンドで検証されます。各設定変更には改訂番号が割り当てられ、スケジュールされたタスクにより、データベースに加えられたすべての作成/更新/削除の操作は検証されます。

本バージョンでは、networking-ovn の内部 DNS 解決のサポートが追加されました。ただし、既知の制限事項が 2 点あり、その 1 つは bz#1581332 で、内部 DNS を介した内部 fqdn 要求が適切に解決されない問題です。

GA リリース版の tripleo では、デフォルトではこの拡張機能が設定されない点に注意してください。bz#1577592 で回避策を参照してください。

ゲートウェイなしでサブネットを作成すると、DHCP オプションは追加されず、そのようなサブネットを使用するインスタンスは DHCP を取得できません。

代わりに、Metadata/DHCP ポートはがこの目的で使用され、インスタンスは IP アドレスを取得することができます。これには、メタデータサービスを有効化する必要があります。外部ゲートウェイのないサブネット上のインスタンスは、OVN metadata/DHCP ポートを介して、DHCP から IP アドレスを取得できるようになりました。

現在の L3 HA スケジューラーは、ノードの優先度を考慮しません。したがって、全ゲートウェイが同じノードでホストされ、負荷は候補間で分散されませんでした。

今回の修正により、ゲートウェイルーターをスケジューリングする際に負荷の最も低いノードを選択するためのアルゴリズムが実装されました。ゲートウェイポートは、最も負荷の低いネットワークノードでスケジュールされ、負荷はノード間で均等に分散されるようになりました。

サブポートが別のハイパーバイザー上の異なるトランクに再割り当てされた際に、バインディングの情報が更新されず、サブポートは ACTIVE に切り替わりませんでした。

今回の修正により、バインディング情報は、サブポートがトランクから削除された時に更新されるようになりました。サブポートは、異なるハイパーバイザーにある別のトランクポートに再度割り当てられると、ACTIVE に切り替わりるようになりました。

python-os-brick

iSCSI ディスカバリーを使用する際に、ノードの起動設定が automatic から default にリセットされていたため、リブート時にサービスが起動しない原因となっていました。この問題は、ディスカバリーを実行した後にスタートアップの値をすべて復元することにより修正されます。

python-zaqar-tests-tempest

tempest プラグインのコレクションは、Queens サイクル中の openstack-*-tests rpm のサブパッケージから抽出されるので、アップグレードには依存関係の問題がありました。ただし、すべてのパッケージに Provides と Obsoletes の正しい組み合わせがあるわけではありませんでした。OSP 13 には -tests (unittest サブ rpm) はありません。

以前のリリースからインストールした -tests を使用してアップグレードを試みると、依存関係の問題により操作は失敗します。

この問題を修正するために、-tests rpm の古いバージョンの Obsoletes が、抽出した先に再度追加されました。