Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

第4章 テクニカルノート

本章には、コンテンツ配信ネットワークからリリースされる Red Hat OpenStack Platform「Ocata」のエラータアドバイザリーの補足情報を記載します。

4.1. RHEA-2016:1245: Red Hat OpenStack Platform 11.0 のバグ修正と機能拡張アドバイザリー

本項に記載するバグは、アドバイザリー RHEA-2017:1245-02 で対応しています。このアドバイザリーについての詳しい情報は、https://access.redhat.com/errata/RHEA-2017:1245.html を参照してください。

instack-undercloud

BZ#1418828
アンダークラウドスタックの rc ファイルは、Keystone v2 rc です。以前のリリースでは、v3 rc ファイル (v3 overcloudrc など) から切り替えた場合に、一部の v3 環境変数が残っていました。そのため、Keystone の認証が正しく機能しない場合がありました。

今回のリリースでは、OpenStack に関連した環境変数はすべて、アンダークラウドの値が設定される前に消去されるようになりました。その結果、stackrc を読み込んだ後に、以前の rc ファイルからの変数は環境には残らなくなり、Keystone の認証が正しく機能するようになりました。
BZ#1256912
image_path パラメーターは使用されなくなりました。今回の更新で、このパラメーターはアンダークラウドの設定ファイルから削除されました。
BZ#1268451
特定の状況では、検証ロジックのエラーが原因で、アンダークラウドの仮想 IP が正しく検証されませんでした。このため、アンダークラウドは誤った仮想 IP でデプロイされる可能性がありました。このエラーは修正され、仮想 IP は正しく検証されるようになりました。仮想 IP の設定に何らかの問題がある場合には、実際にデプロイメントが実行される前に検出されます。

openstack-cinder

BZ#1434494
以前のリリースでは、同じイメージからのボリューム作成要求を同時に実行すると、Block Storage サービスのイメージキャッシュに複数のエントリーが追加される可能性がありました。このため、同じイメージのイメージキャッシュエントリーが重複して、スペースが無駄になっていました。

今回の更新では、この問題を防ぐために同期のロックが実装され、イメージからのボリューム作成の最初の要求がキャッシュされ、それ以外のリクエストはすべてキャッシュされたイメージを使用するようになりました。

openstack-glance

BZ#1396794
今回の機能拡張により、「glance-manage db purge」は、経過時間が 1 日未満の行を削除できるようになりました。この機能は、オペレーターがこの操作を定期的に実行する必要がある場合があるため追加されました。
その結果、「age_in_days」のオプションを「0」に設定することができるようになりました。

openstack-gnocchi

BZ#1197163
Time Series Database as a Service (gnocchi) および Aodh API のエンドポイントは、REST API 上で「/healthcheck」HTTP エンドポイントを公開するようになりました。このエンドポイントを要求すると、サービスのステータスを確認することが可能で、これには認証は必要ありません。

openstack-heat

BZ#1414779
以前のリリースでは、FAILED 状態のリソースに pre-update フックが設定されていると、Orchestration サービスはフックがアクティブであることを示すイベントを記録し、ユーザーがフックを消去するのを待たずに代わりのリソースを即時に作成していました。その結果、tripleoclient サービスは、(イベントに基づいて) フックが保留中であると見なしましたが、代わりのリソースにはフックが設定されていないため、消去を試みても失敗し、director はオーバークラウドを更新できず、次のようなメッセージが表示されていました。 

    ERROR: The "pre-update" hook is not defined on SoftwareDeployment
    "UpdateDeployment"
    
これは、フックを使用する他のクライアント側のアプリケーションにも影響を及ぼしていました。director では、この問題のために、2 台のコントローラーノードで UpdateDeployment が順次ではなく同時に実行され、1 回に更新されるのは、1 台のコントローラーのみでした。

今回の更新では、Orchestration サービスは、リソースの状態に拘らず、ユーザーによってフックが消去されるまで一時停止するようになりました。このため、UpdateDeployment リソースが FAILED の状態でも、director のオーバークラウドの更新は完了するようになりました。
BZ#1320771
以前のリリースでは、スタックの状態が正しくない場合に Orchestration サービスがリソースのステータスをリセットすることができましたが、更新が再度トリガーされると、サービスはその操作に失敗していました。このため、リソースは進行中の状態で止まってしまい、デプロイメントのブロックを解除するのにデータベースを修正する必要がありました。

今回のリリースでは、Orchestration サービスは、スタックのステータス設定時に全リソースのステータスを設定するようになりました。これにより、リソースが進行中の状態で停止することはなくなり、操作の再試行を正常に実行できるようになりました。

openstack-manila

BZ#1386249
今回の更新により、CephFS ネイティブドライバーは OpenStack File Share Service (manila) のコアインフラストラクチャーと共に機能が拡張されました。CephFS ネイティブドライバーは、読み取り専用のファイル共有をサポートするようになりました。また、「access_list」には含まれていないバックエンドルールを削除することにより、リカバリーモードが向上されました。

openstack-manila-ui

BZ#1393893
今回の機能拡張では、パブリックのファイル共有の作成を Dashboard で無効にできるようになりました。
作成処理中にファイル共有をパブリックにマークするチェックボックスを表示しないように Dashboard を設定することができます。デフォルトのオプションでは、このボックスにチェックマークはなしでプライベートのファイル共有が作成されます。

openstack-neutron

BZ#1385338
neutron-openvswitch-agent でセキュリティーグループのトランク機能を実装するには、openvswitch のファイアウォールドライバーが必要です。このドライバーには現在 BZ# 1444368 のバグがあり、同じコンピュートノード上にある異なるネットワークセグメントで同じ MAC アドレスのポートが 2 つある場合には、受信トラフィックが間違って照合されます。

このため、サブポートが親ポートと同じ MAC アドレスの場合には、受信トラフィックは一方のポートには正しく照合されません。

トラフィックを正しく処理するための回避策として、親ポートとサブポートでポートセキュリティーを無効にします。

たとえば、UUID 12345 のポートのポートセキュリティーを無効にするには、そのポートに関連付けられたセキュリティーグループを削除する必要があります。
 openstack port set --no-security-group --disable-port-security 12345

そのポートにはセキュリティーグループのルールは一切適用されず、トラフィックのフィルタリングおよび ip/mac/arp スプーフィングに対する保護は適用されない点に注意してください。
BZ#1436576
DVR の設定で、「test_l3_agent_scheduler.py」の「test_add_list_remove_router_on_l3_agent」が正常に終了しませんでした。このテスト手順は、新規ルーターの作成時に、以前にバインディング済みであっても、ネットワークインターフェースを L3 エージェントにバインディングするように試みていました。
この問題は修正され、ルーターへのインターフェース追加と L3 エージェントへの割り当ては、テストによって実行されるまでは行われないようになったので、テストは正常に終了するようになりました。

openstack-neutron-lbaas

BZ#1325861
今回の機能拡張で、サーバーによって停止中と検出された LBaaS エージェントのロードバランサーを自動的に再スケジュールする機能が追加されました。以前は、ロードバランサーをスケジュールして、複数の LBaaS エージェントで実行することができましたが、ハイパーバイザーが停止した場合には、そのノードに対してスケジュールされていたロードバランサーは、操作を停止していました。
今回の更新では、これらのロードバランサーは別のエージェントに自動的に再スケジュールされるようになりました。この機能は、デフォルトで無効になっており、「allow_automatic_lbaas_agent_failover」を使用して管理されます。
BZ#1326224
今回の機能拡張により、「HaproxyNSDriver」クラス (v2) に「ProcessMonitor」クラスが実装されました。このクラスは、必要に応じて「external_process」モジュールを活用して HAProxy プロセスを監視/再起動します。LBaaS エージェント (v2) は「external_process」関連のオプションを読み込み、HAProxy が予期せず停止した場合には、設定済みのアクションを実行します。

openstack-nova

BZ#1352922
今回のリリースでは、多数のインスタンスがあるシステムに対して使用状況の統計を要求してリソースが大量に消費されるのを回避するために、ページネーションのサポートが追加されました。nova API simple-tenant-usage エンドポイントの v2.40 マイクロバージョンでは、新しいオプションのクエリーパラメーター「limit」と「marker」がページネーションに使用されます。「marker」オプションは開始点を設定し、「limit」オプションは開始点よりも後に表示されるレコード数を設定します。「limit」が設定されていない場合には、nova は設定可能な「max_limit」 (デフォルト値は 1000) を使用します。古いマイクロバージョンはこれらの新しいクエリーパラメーターを受け入れませんが、max_limit の適用を開始するので、結果が切り捨てられる場合があります。DoS ライクな使用状況の統計要求を回避して、応答が切り捨てられないようにするには、新しいマイクロバージョンを使用することを検討してください。

openstack-sahara

BZ#1337664
今回の更新により、バージョン 5.1.0 MapR プラグインがサポートされるようになりました。

openstack-selinux

BZ#1431556
DPDK を有効にしたインスタンスの起動に関する SELinux ポリシーは完全ではないため、SELinux が enforcing モードの場合には DPDK を使用するインスタンスの起動は失敗して、openvswitch および svirt に関する AVC 拒否が /var/log/audit/audit.log* に表示されます。

回避策として、 以下のリンク先のセクション 4.4.1.2 に記載されているように、DPDK を使用する各コンピュートノードで SELinux を permissive に設定します。

SELinux の状態とモードの永続的変更

これにより、DPDK を有効化した仮想マシンを起動することができます。これは回避策で、この問題を詳しく調査している間の一時的な対策となる見込みです。

openstack-tripleo-common

BZ#1326549
Heat 内のノードを削除する際には、バックグラウンドでそのプロセスがまだ実行中でも、削除のコマンドが終了し、プロンプトが返されていました。この直後に別のコマンドを実行すると、競合が発生して、コマンドが失敗していました。このプロセスの動作は変更され、プロセスが完全に終了した場合にのみプロンプトが返されるようになりました。
BZ#1242422
director で自動フェンシング設定を使用して、より簡単に高可用性のデプロイメントとアップグレードを実行できるようになりました。この新機能を活用するには、「overcloud generate fencing」コマンドを使用してください。

openstack-tripleo-heat-templates

BZ#1425507
neutron-openvswitch-agent サービスを停止する場合には、停止の処理が正常に終了するのに長時間かかる場合があり、systemd によって強制終了されていました。このような場合には、実行中の neutron-rootwrap-daemon がシステムに残ってしまい、neutron-openvswitch-agent サービスが再起動できなくなっていました。
この問題は修正され、rpm スクリプレットが孤立した neutron-rootwrap-daemon を検出して終了するようになったので、neutron-openvswitch-agent サービスは正常に起動/再起動するようになりました。
BZ#1435271
今回のリリースでは、「clustercheck」は Galera の「wsrep_cluster_address」オプションで指定したノードでのみ実行されるようになりました。この変更は、Galera が 専用ノードで実行されるユースケース (コンポーザブルロールで可能となった) を考慮して実装されました。以前のリリースでは、マイナーな更新の際には「clustercheck」は、Galera も同じノードにあることを前提として、pacemaker を稼働中の全ノードで実行されていました。
BZ#1312962
director は「/etc/rabbitmq/rabbitmq.config」に「tcp_list_options」 スタンザを 2 回設定していました。これによる悪影響はありませんでしたが、混乱を招く可能性がありました。今回の修正により重複していたスタンザは削除され、設定ファイルには「tcp_list_options」スタンザが 1 回のみ記載されるようになりました。
BZ#1372589
puppet の hieradata を使用して、libvirtd によって起動された QEMU インスタンス向けに max_files と max_processes を設定できるようになりました。これは、適切な puppet クラスが含まれた環境ファイルで設定することができます。たとえば、max_files を 32768 に、max_processes を 131072 に指定するには、以下の設定を使用します。

parameter_defaults:
  ExtraConfig
    nova::compute::libvirt::qemu::max_files: 32768
    nova::compute::libvirt::qemu::max_processes: 131072
    
また、libvirtd によって起動された QEMU インスタンスは多数のファイル記述子またはスレッドを使用する可能性があるため、今回の更新でこれらの値がデフォルト値になりました。これは、各コンピュートノード上でホストされているコンピュートのゲストと、各インスタンスのアタッチ先の Ceph RBD イメージによって異なります。大型のクラスターでは、これらの制限値を設定可能である必要があります。

これらの新しいデフォルト値により、Compute サービスは 700 以上の OSD を使用できるはずです。以前のリリースでは、max_files の数値 (元は 1024) が低いために課される制限として見なされていました。
BZ#1438890
OpenStack Platform 10 には、Big Switch エージェントの誤った設定が含まれていました。同梱されている Heat テンプレートと共に Big Switch エージェントをデプロイすると、デプロイメントが失敗していました。今回の修正により、Heat テンプレートが Big Switch エージェントを正しくデプロイするように更新され、director はコンポーザブルロールに Big Switch エージェントを適切にデプロイするようになりました。
BZ#1400262
Memcached のデフォルトのメモリー設定は使用可能な RAM 全体の 95 パーセントだったので、リソースの競合が発生する場合がありました。今回の修正により、デフォルト値は使用可能な RAM 全体の 50 パーセントに下げられました。この値は「MemcachedMaxMemory」で設定することも可能です。このため、リソースの競合が発生する可能性が低くなりました。
BZ#1440213
オーバークラウドのパッケージ更新のスクリプトのバグが原因で、更新用に提供されているパッケージがない場合でも、クラスターサービスが必ず再起動されていました。今回の修正により、保留中のパッケージ更新があるかどうかを判断するチェックが正しく機能するようになり、更新するパッケージがない場合には、yum update スクリプトは終了し、クラスターサービスは再起動されません。
BZ#1225069
セキュリティー上の理由により、オーバークラウドではデフォルトで SSH キーベースのアクセスのみが許可されています。virt-customize ツールを使用すると、オーバークラウドのディスクイメージで root パスワードを設定することができます。このツールは、Red Hat Enterprise Linux Extras チャンネルで提供しています。ツールをインストールし、オーバークラウドのイメージをダウンロードした後には、以下のコマンドを実行して root パスワードを変更します。

$ virt-customize -a overcloud-full.qcow2 --root-password password:my_root_password

この操作は、「openstack overcloud image upload」コマンドで glance にイメージをアップロードする前に実行してください。

openstack-tripleo-puppet-elements

BZ#1441923
「tuned-profiles-cpu-partitioning」パッケージが「overcloud-full.qcow2」イメージに事前インストールされるようになりました。DPDK デプロイメントの場合には、このパッケージはホストのチューニングと CPU の用途分けをサポートするのに必要です。director には、必要な引数を使用して「tuned」サービスを有効にするための適切な first-boot スクリプトが含まれます。

os-net-config

BZ#1409097
現在、Red Hat OpenStack Platform director 10 で SRIOV を有効にしている場合には、compute.yaml file で NIC ID (例: nic1、nic2、nic3 など) を使用するとオーバークラウドデプロイメントが失敗します。

デプロイメントが正常に完了するようにするには、回避策として、NIC ID の代わりに NIC の名前 (例: ens1f0、ens1f1、ens2f0 など) を使用する必要があります。

puppet-ceph

BZ#1388515
以前のバージョン (Red Hat Ceph Storage 1.3) を使用する外部の Ceph Storage クラスターと統合された Red Hat OpenStack Platform 環境をアップグレードまたはデプロイする場合には、後方互換性を有効にする必要があります。そのためには、アップグレードまたはデプロイメント中に environments/puppet-ceph-external.yaml で以下の行をコメント解除してください。

parameter_defaults:
  # Uncomment if connecting to a pre-Jewel or RHCS1.3 Ceph Cluster
  RbdDefaultFeatures: 1
BZ#1413980
今回のリリースでは、CephFS のデプロイに必要な puppet モジュールが提供されるようになりました。これにより、director で、CephFS バックエンドを使用する OpenStack Shared File Systems サービス (openstack-manila) をデプロイすることができます。

puppet-pacemaker

BZ#1437417
以前のリリースでは、以下のようなエラーでデプロイメントが失敗することがありました。
	  Error: /Stage[main]/Pacemaker::Corosync/Exec[Start Cluster tripleo_cluster]/returns: change from notrun to 0 failed: /sbin/pcs cluster start --all returned 1 instead of one of 0

今回の更新により、クラスターの設定中に puppet pacemaker が失敗する可能性のあったわずかな競合状態が解消されました。その結果、デプロイメントはエラーなしで正しく機能するようになりました。
BZ#1379741
以前のリリースでは、Pacemaker のサービスはすべて同じロールにする必要がありました。

今回の更新の新たな機能により、Pacemaker の管理対象サービスでコンポーザブルロールを使用できるようになりました。Pacemaker の管理対象サービスをより多くの異なるノードにスケールアウトするためには、この機能が必要です。

puppet-tripleo

BZ#1438602
以前のリリースでは、OpenStack Dashboard サービスはデプロイメントの不適切なステップで設定されていました。このため、デプロイメント中に horizon が一時的に使用できなくなり、httpd サービスの再起動が追加で実行されていました。

今回の更新により、OpenStack Dashboard の設定は、httpd 設定の残りと同時に行われるように修正されました。その結果、オーバークラウドの実行時に、horizon が一時的に利用不能になることはなくなりました。

python-django-horizon

BZ#1271019
管理者はボリュームの譲渡操作時にユーザー認証情報を記録する必要がありますが、それを手動で行うのは煩わしい作業です。

今回の更新により、認証情報をダウンロードするための新たなボタンがボリュームの譲渡の画面に追加され、情報を簡単に保存できるようになりました。これにより、管理者はボタンをクリックして、情報をダウンロードして CSV ファイルを自分のローカルマシンに保存することができます。
BZ#1388171
nova-api ワーカーにおけるメモリーの肥大化問題を防ぐために、simple-tenant-usage API 拡張機能にページネーションロジックが追加されました。
BZ#1434704
以前のリリースでは、アンダースコアが含まれたユーザー ID の処理がコード内で正しく行われないため、ユーザー ID にアンダースコアが含まれている場合には、プロジェクト/ドメインのメンバーを更新できませんでした。

今回の更新により、ユーザー ID を処理するコードが修正され、アンダースコアを正しく処理するようになりました。その結果、アンダースコアが含まれていても、プロジェクト/ドメインのメンバーを更新できるようになりました。

python-heatclient

BZ#1437334
イベントの取得プロセスを最適化した後に、「openstack stack hook poll」コマンドは、保留中のフックが存在していて返す必要がある場合でも、返すのを停止していました。この問題は修正され、フックは正しく返されるようになりました。

python-openstackclient

BZ#1402772
以前のリリースでは、「openstack network」コマンドは「--os-interface」スイッチを無視していました。そのため、他のインターフェースが指定されていても、このコマンドはすべて「パブリック」のエンドポイントを使用していました。今回のリリースでは、このスイッチに対するサポートが追加され、「openstack network」コマンドは「--os-interface」スイッチで指定されたエンドポイントを正しく使用するようになりました。

python-oslo-messaging

BZ#1427792
以前のリリースでは、Oslo Messaging のリモートプロシージャーコール (RPC) メッセージ受信確認 はスレッドセーフではありませんでした。そのため、競合状態により、Ceilometer で RPC タイムアウトが発生していました。今回のリリースでは Oslo Messaging のメッセージ受信確認は修正され、Ceilometer は正しく応答するようになりました。
BZ#1414497
以前のリリースでは、Oslo Messaging は設定を正しく初期化していませんでした。その結果、「nova-manage」クライアントは起動中に失敗していました。今回のリリースではこのエラーは修正され、「nova-manage」は正しく起動するようになりました。

python-tripleoclient

BZ#1353049
以前のリリースでは、更新またはアップグレードが失敗しても、0 の終了値が返されていたので、この値に基づいて、処理が正常に完了したかどうかを確認することはできませんでした。今回の更新により、更新またはアップグレードが失敗すると、例外が発生し、OpenStackClient に対してエラー状態であることを示しますようになりました。その結果、OpenStackClient は処理が正常に完了した場合にのみ 0 の終了値を返し、エラーが発生した場合には 0 以外の値を返すようになりました。
BZ#1400386
以前のリリースでは、「openstack overcloud image upload」は、オーバークラウドイメージのアップロードまたは更新時に「--image-path」の引数を無視していました。そのため、作業ディレクトリー内のイメージしか使用できませんでした。今回のリリースでは、「--image-path」の引数のサポートが追加され、この引数によって指定された異なるディレクトリーからイメージを正常にアップロードできるようになりました。

rhosp-director

BZ#1247019
フェンシングデバイスとホストデバイスの名前が同じ場合には、Pacemaker は連続的にクラッシュします。この問題を回避するには、「fence-」のプレフィックスをフェンシングデバイスに追加してください。名前をこのように設定した場合には、クラスターはエラーなしで機能します。