リリースノート

互換モード

#subscription-manager repos --enable=[reponame]
#subscription-manager repos --disable=[reponame]
{ "devices": [ {
        "type": "nic",
        "bus": "pci",
        "address": "0000:00:02.0",
        "mac": "01:22:22:42:22:21",
        "tags": ["nfvfunc1"]
    },    {
        "type": "disk",
        "bus": "scsi",
        "address": "1:0:2:0",
        "serial": "disk-vol-2352423",
        "tags": ["dbvolume"]
    }
}
今回の機能拡張により「admin」ユーザーは管理コンソールを使用してインスタンスに割り当てられている Floating IP の一覧を確認できるようになりました。この一覧はデプロイメント内の全プロジェクトを対象とします。
以前のリリースでは、この情報はコマンドラインでのみ取得可能でした。
今回の機能拡張により、仮想デバイスロールのタグ付けがサポートされるようになりました。この機能は、インスタンスのオペレーティングシステムに、そのインスタンスを実行している仮想デバイスについての追加情報が必要な場合があるために追加されました。たとえば、複数のネットワークインターフェースのあるインスタンスでは、適切にプロビジョニングするために、ゲストのオペレーティングシステムの用途を区別する必要があります
今回の更新で、仮想デバイスロールのタグ付けにより、ユーザーはインスタンスの作成時に、仮想デバイスにタグを付けられるようになりました。これらのタグは、メタデータ API を使用して、コンフィグドライブ (有効化されている場合) を介して (他のデバイスメタデータとともに) インスタンスに提示されます。詳しい情報は、『Red Hat OpenStack Platform 10 ネットワークガイド』の「Use Tagging for Virtual Device Identification」の章を参照してください: https://access.redhat.com/documentation/en/red-hat-openstack-platform/
今回の更新により、オーバークラウドのコントローラーノード上の iptables ファイアウォールが有効化されてセキュリティーが強化されました。その結果、必要なポートが開放され、オーバークラウドは以前のとおりに機能し続けます。
director を使用して Ceph RBD を Block Storage バックアップターゲットとして設定できるようになりました。これにより、ボリュームを Ceph ターゲットにバックアップするように設定してオーバークラウドをデプロイすることができます。デフォルトでは、ボリュームのバックアップは「backups」という名前の Ceph プールに保管されます。

バックアップの設定は、以下の環境ファイル (アンダークラウド上) で設定されます。

/usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml
今回のリリースでは、リセラーのユースケースのセキュリティー強化のために 2 要素認証が必要となりました。
本リリースでは、高可用性アーキテクチャーは簡素化されたため、サービスの再起動が必要な際のプロセスの侵襲性が低くなりました。スケーリングの操作中には、必要なサービスのみが再起動されます。以前のリリースでは、スケーリング操作でクラスター全体の再起動が必要でした。
今回の更新には、OSP director を使用してデプロイされたオーバークラウドのバージョンを特定するためのリリースファイルが含まれるようになりました。この情報により、インストール済みのバージョンが明確にわかるので、デバッグに役立ちます。overcloud-full イメージには新規パッケージ (rhosp-release) が含まれています。旧バージョンからアップグレードする場合にもこの RPM がインストールされます。リリースファイルは、OSP 10 以降の全バージョンに含まれます。これは Red Hat OpenStack Platform director ベースのインストールにのみ適用されますが、rhosp-release パッケージを手動でインストールしても同じ結果を得ることができます。
RBD バックエンドドライバー (Ceph Storage) を OpenStack Compute (nova) の一時ディスクにすると、以下の 2 つの追加設定を libvirt に適用します。

hw_disk_discard : unmap
disk_cachemodes : network=writeback

これにより、Ceph プール上の未使用ブロックを再利用し、ネットワークの書き込みをキャッシュすることができるので、RBD ドライバーを使用する OpenStack Compute 一時ディスクのパフォーマンスが向上します。

http://docs.ceph.com/docs/master/rbd/rbd-openstack/ も参照してください。
今回の機能拡張により、「heat-manage」が「heat-manage reset_stack_status」サブコマンドをサポートするようになりました。このサブコマンドは、「heat-engine」がデータベースと通信できないために、進行中のスタックがそのままで停止してしまう状況に対応するために追加されました。この問題が発生した場合には、管理者がステータスをリセットして、スタックが再度更新できるようにする方法が必要でした。
この機能が拡張された結果、管理者は「heat-manage reset_stack_status」コマンドで進行中の状態で停止したスタックをリセットすることができるようになりました。
「openstack baremetal」ユーティリティーにより、ブート設定中に特定のイメージを指定できるようになりました。具体的には、「--deploy-kernel」および「--deploy-ramdisk」のオプションを使用してカーネルまたは ramdisk イメージをそれぞれ指定できます。
今回の更新により、オーバークラウドのデプロイ時に追加の環境ファイルを使用してオーバークラウド内の Object Storage サービス (swift) を無効にすることができます。この環境ファイルには、以下の内容を記載する必要があります。

resource_registry:
  OS::TripleO::Services::SwiftProxy: OS::Heat::None
  OS::TripleO::Services::SwiftStorage: OS::Heat::None
  OS::TripleO::Services::SwiftRingBuilder: OS::Heat::None

その結果、Object Storage サービスはオーバークラウドで実行されなくなり、オーバークラウドの Identity サービス内の Object Storage サービスのエンドポイントはなくなります。
「ceph-osd」インスタンスを SELinux ポリシーで制限できるようになりました。OSP 10 では、新規デプロイでは、Ceph Storage ノード上で SELinux が「enforcing」モードで設定されるようになりました。
通常、OpenStack における OVS+DPDK の設定は、オーバークラウドのデプロイ後に手動で実行されます。これは、多数のコンピュートノードが対象となる場合にはオペレーターにとって非常に困難で、退屈な作業となる可能性がありました。今回の更新により OVS+DPDK のインストールは tripleo で自動化されました。以前は手動で行われていた DPDK のハードウェア機能の特定は、イントロスペクション中に自動化されました。また、ハードウェアの検出により、Heat テンプレートの設定に必要な情報がオペレーターに提供されるようになりました。現在、DPDK 対応のハードウェアを搭載しているコンピュートノードと、DPDK 対応のハードウェアを搭載していないコンピュートノードを共存させることはできません。
「ironic」Python エージェントは以下のハードウェア情報を検出して swift のブロブに保管します。
* ヒュージページサポートの CPU フラグ: pse が存在する場合には 2 MB のヒュージページがサポートされ、pdpe1gb が存在する場合には 1 GB のヒュージページがサポートされます。
* IOMMU の CPU フラグ: VT-d/svm が存在する場合には IOMMU がサポートされます。ただし、BIOS で IOMMU サポートが有効化されていることが条件です。
* 互換性のある NIC: DPDK にホワイトリストされている NIC の一覧 (http://dpdk.org/doc/nics に記載) と対照します。

上記の機能のいずれも搭載されていないノードは、DPDK を使用するコンピュートの役割には使用できません。

* オペレーターは、コンピュートノードで DPDK を有効にするためのプロビジョニングを使用することができます。
* コンピュート対応で DPDK NIC が搭載されていると確認されたノード向けのオーバークラウドイメージには、OVS の代わりに OVS+DPDK パッケージが使用されます。また、「dpdk」および「driverctl」のパッケージも含まれます。
* DPDK 対応の NIC のデバイス名は、T-H-T から取得されます。DPDK NIC の PCI アドレスは、デバイス名から識別される必要があります。これは、PCI のプロービング中に DPDK NIC をホワイトリストするのに必要です。
* ヒュージページは DPDK を使用するコンピュートノードで有効にする必要があります。
* DPDK Poll Mode Driver (PMD) に確保される CPU コアが一般のカーネルバランシングに使用されてアルゴリズムの処理とスケジューリングを中断しないようにするために、CPU を分離する必要があります。
* DPDK を有効にした NIC を使用する各コンピュートノードでは、puppet によってホワイトリストされた NIC の DPDK_OPTIONS、CPU マスク、および DPDK PMD のメモリーチャネル数が設定されます。DPDK_OPTIONS は /etc/sysconfig/openvswitch で設定する必要があります。

「Os-net-config」は以下のステップを実行します。
* 指定したインターフェースの pci アドレスを特定することにより、そのインターフェースを dpdk ドライバー (デフォルトは vfio-pci ドライバー) に関連付けます。ドライバーを永続的にバインディングするために driverctl が使用されます。
* ovs_user_bridge と ovs_dpdk_port のタイプを理解して、ifcfg スクリプトを適切に設定してください。
* 「タイプ」ovs_user_bridge は OVS タイプ OVSUserBridge と解釈され、これに基づいて OVS がデータパスタイプを「netdev」に設定します。
* 「タイプ」 ovs_dpdk_port は OVS タイプ OVSDPDKPort と解釈され、これに基づいて OVS がインターフェースタイプを「dpdk」としてポートをブリッジに追加します。
* ovs_dpdk_bond を理解して ifcfg スクリプトを適切に設定します。

DPDK を有効にした NIC を使用する各コンピュートノードで puppet により以下のステップが実行されます。
* /etc/neutron/plugins/ml2/openvswitch_agent.ini [OVS] datapath_type=netdev vhostuser_socket_dir=/var/run/openvswitch での OVS+DPDK の有効化
* qemu により所有される /var/run/openvswitch での vhostuser ポートの設定

各コントローラーノードで puppet により以下のステップが実行されます。
* nova.conf で NUMATopologyFilter を scheduler_default_filters に追加します。

その結果、上記の機能拡張されたプラットフォームの認識の自動化が完了し、QA テストで検証されます。
以前、Red Hat Enterprise Linux OpenStack Platform 7 では、各ロールで使用可能なネットワークが固定されていたため、任意のロール上で任意のネットワークを使用するカスタムネットワークトポロジーは利用できませんでした。
今回の更新により、Red Hat OpenStack Platform 8 以降のバージョンでは、任意のネットワークを任意のロールに割り当てることができるようになりました。
その結果、カスタムネットワークトポロジーが可能となりましたが、各ロールのポートはカスタマイズする必要があります。openstack-tripleo-heat-templates の「environments/network-isolation.yaml」ファイルを確認して、カスタム環境ファイルまたは「network-environment.yaml」で各ロールのポートを有効にする方法を参照してください。
今回の更新で複数のテーマ設定がサポートされるようになりました。これは、ユーザーがフロントエンドを使用してテーマを動的に変更できるようにするために追加されました。一部のユースケースには、明るいテーマと暗いテーマを切り替える機能や、アクセシビリティー上の理由から高コントラストを有効にする機能などが含まれます。
その結果、ユーザーは実行時にテーマを選択することができます。
Red Hat OpenStack Platform director は OpenStack Block Storage (cinder) v3 API エンドポイントを OpenStack Identity (keystone) に作成して、より新しい Cinder API バージョンをサポートするようになりました。
今回の機能拡張により、ドメインスコープのトークンを Dashboard (horizon) のログインに使用することができるようになりました。
この機能は、ドメインスコープのトークンを必要とする、よりリッチなロールセットを使用する場合に keystone v3 の認証管理を完全にサポートするために追加されました。django_openstack_auth はこのタイプのセッション用トークンの取得と維持をサポートする必要があります。
その結果、horizon ではドメインスコープのトークンを Red Hat OpenStack Platform 9 より利用できるようになりました。
今回の機能拡張により、「sahara-image-element」上のメインスクリプトが更新され、サポートされているプラグインのイメージだけを作成できるようになりました。たとえば、以下のコマンドを実行して、Red Hat Enterprise Linux 7 を使用する CDH 5.7 イメージを作成することができます。
----
>> ./diskimage-create/diskimage-create.sh -p cloudera -v 5.7

Usage: diskimage-create.sh
         [-p cloudera|mapr|ambari]
         [-v 5.5|5.7|2.3|2.4]
         [-r 5.1.0]
----
AODH は MYSQLをデフォルトのデータベースバックエンドとして使用するようになりました。以前のリリースでは、Ceilometer から AODH の移行を容易にする目的で、AODH は MongoDB をデフォルトのバックエンドとして使用していました。
今回の更新で、オーバークラウドのイメージに Red Hat Cloud Storage 2.0 バージョンがインストールされるようになりました。
OpenDaylight はテナントで設定可能なセキュリティーグループをサポートするようになり、セキュリティーグループルールに照合されたトラフィックのみが許可されるようになりました。現在は IPv4 トラフィックのみが照合/フィルタリング可能で、IPv6 には対応していません。
デフォルトでは、各テナントに「default」という名前のセキュリティーグループが使用されます。このセキュリティーグループには、デフォルトのルールがあり、default セキュリティーグループと関連付けられたインスタンス間の相互通信のみが許可されます。その結果、default グループからの送信トラフィックと default グループ内の相互通信のみが許可され、default グループ外からの受信トラフィックはデフォルトでドロップされます。
今回の機能拡張により、Red Hat OpenStack Platform director で Open vSwitch (OVS) ファイアウォールドライバーを設定するための新しいパラメーター「NeutronOVSFirewallDriver」が追加されました。
このパラメーターは、neutron OVS エージェントがセキュリティーグループを実装するための新たなメカニズムである「openvswitch」ファイアウォールをサポートしているために追加されました。「NeutronOVSFirewallDriver」によりユーザーは使用する実装を直接制御することができます。
「hybrid」: neutron が以前の iptables/ハイブリッドベースの実装を使用するように設定します。
「openvswitch」: 新たなフローベースの実装を有効にします。 
新しい Open vSwitch (OVS) ファイアウォールドライバーにより、パフォーマンスが向上し、プロジェクトネットワークへの接続に使用するインターフェースとブリッジの数が削減されます。その結果、ユーザーは新たなセキュリティーグループの実装をより簡単に評価することができるようになりました。
director を使用して Ceph RadosGW をオブジェクトストレージのゲートウェイとしてデプロイできるようになりました。そのためには、オーバークラウドのデプロイメントに /usr/share/openstack-tripleo-heat-templates/environmens/ceph-radosgw.yaml を追加します。この Heat テンプレートを使用する場合には、デフォルトの Object Storage サービス (swift) はデプロイされません。
今回の更新で、UI を使用してノードを追加できるようになりました。
OpenStack Data Processing サービスは、HDP (Ambari) プラグインのバージョン 2.4 をサポートするようになりました。
https://bugs.launchpad.net/tripleo/+bug/1630247 に記載されているように、アップストリームの Newton TripleO では Sahara サービスがデフォルトで無効化されましたが、Red Hat OpenStack Platform 9 から Red Hat OpenStack Platform 10 へのアップグレード手順では、Sahara サービスはデフォルトで有効化/維持されます。アップグレード後に Sahara は不要であるとオペレーターが判断した場合には、コントローラーのアップグレードとコンバージステップのコマンドで「-e 'major-upgrade-remove-sahara.yaml'」の環境ファイルを指定する必要があります。この環境ファイルは、特にコンバージのステップで末尾に指定する必要がありますが、混乱を避けるために両方のステップで末尾に指定することができます。このオプションを指定すると、Sahara サービスはメジャーアップグレード後に再起動しなくなります。
この方法により、Sahara サービスは OSP9 から OSP10 へのアップグレード中に適切に処理されます。また現在も、必要な場合には、オペレーターは Sahara を明示的に無効にすることが可能です。
今回の更新により、追加の環境ファイルを使用してオーバークラウドをデプロイすることによって、Object Storage サービス (swift) に追加の RAW ディスクを設定できるようになりました。以下に例を示します。

  parameter_defaults:
    ExtraConfig:
      SwiftRawDisks:
        sdb:
          byte_size: 2048
          mnt_base_dir: /src/sdb
        sdc:
          byte_size: 2048

その結果、Object Storage サービスはローカルノードの「root」ファイルシステムのみに限定されなくなりました。
ハードウェアのプロビジョニング段階に汎用ノードをデプロイできるようになりました。これらのノードは、汎用オペレーティングシステム (Red Hat Enterprise Linux) を使用してデプロイされ、ユーザーはそれらのノードに直接、追加のサービスをデプロイすることができます。
ironic-python-agent イメージが含まれているパッケージには、依存関係として rhosp-director-images RPM が必要でしたが、Red Hat OpenStack Platform director を利用しなくても OpenStack Bare Metal Provisioning サービス (ironic) の一般的な用途に ironic-python-agent を使用することが可能です。今回の更新で依存関係が変更され、以下のようになりました。

- rhosp-director-images RPM は rhosp-director-images-ipa RPM を必要とする。
- rhosp-director-images-ipa RPM は rhosp-director-images RPM を必要としない。

ユーザーは ironic-python-agent イメージを単独でインストールすることができるようになりました。
今回の更新により、IPMItool ドライバー向けに socat ベースのシリアルコンソールが追加されました。これは、ユーザーが仮想ノードのコンソールにアクセスするのと同じ方法でベアメタルノードのシリアルコンソールにアクセスする必要がある場合があるために追加されました。その結果、新しいドライバー「pxe_ipmitool_socat」が追加され、「socat」ユーティリティーを使用したシリアルコンソールがサポートされるようになりました。
OpenStack Data Processing サービスは、HDP (Ambari) プラグインのバージョン 2.3 をサポートするようになりました。
今回のリリースは、コンポーザブルロールを特徴としており、TripleO はコンポーザブルな方法でデプロイ可能となりました。これにより、各ノードで実行する必要のあるサービスをユーザーが選択することができるので、複雑なユースケースをサポートできます。
director では、OSP コントローラーノードとコロケーションされている RADOS Gateway (RGW) サービスに対する HAproxy ロードバランシングと SSL 終了を設定できるようになりました。
今回のリリースでは、OpenDaylight コントローラープラットフォーム自体におけるクラスタリングはサポートされませんが、neutron API サービスに対する HA が提供されます。
今回の更新で、IP トラフィックは QoS ポリシーにアタッチされた DSCP マーキングルールによって管理できるようになりました。このポリシーは、ネットワークとポートに適用されます。
これは、特にリアルタイムの情報やクリティカルな制御データを処理する場合に、トラフィックソースによって、ネットワークレベルで必要とされる優先順位のレベルが異なる場合があるために追加されました。その結果、特定のポートとネットワークからのトラフィックは DSCP フラグでマークすることができるようになりました。本リリースでは、Open vSwitch のみがサポートされている点に注意してください。
Telemetry サービス (ceilometer) はデフォルトのメーターディスパッチャーバックエンドに Gnocchi を使用するようになりました。Gnocchi はよりスケーラブルで、Telemetry サービスの今後の方向性に沿っています。
今回の機能拡張により、RabbitMQ に Queue Master 分散の新たな HA 機能が導入されました。そのストラテジーの 1 つは「min-masters」で、最小数のマスターをホストするノードを選択します。
この機能は、コントローラーの 1 つが利用できなくなる可能性があり、その場合にはキューの宣言中に利用可能なコントローラーに Queue Master が配置されるために追加されました。利用不可だったコントローラーが再度利用可能になると、新たに宣言されたキューのマスターは、キューマスターの数が明らかに低いコントローラーを優先するようには配置されなかったため、分散が不均衡となって、複数のフェイルオーバーが発生した場合にコントローラーにかかる負荷が大幅に高くなる可能性がありました。
そのため、今回の機能拡張でコントローラーのフェイルオーバーの発生後には、キューがコントローラー全体に広げられるようになりました。
今回の更新で、オーバークラウドからモニタリングインフラストラクチャーへの接続を有効にする新機能により、オーバークラウドノードに可用性管理エージェント (sensu-client) がデプロイされるようになりました。 

モニタリングエージェントのデプロイメントを有効にするには、「/usr/share/openstack/tripleo-heat-templates/environments/monitoring-environment.yaml」という環境ファイルを使用して、以下のパラメーターをその YAML 設定ファイルに指定します。

MonitoringRabbitHost: モニタリングを目的とする RabbitMQ インスタンスを実行するホスト
MonitoringRabbitPort: モニタリングを目的とする RabbitMQ インスタンスが実行されるポート
MonitoringRabbitUserName: RabbitMQ インスタンスに接続するためのユーザー名
MonitoringRabbitPassword: RabbitMQ インスタンスに接続するためのパスワード
MonitoringRabbitVhost: モニタリング目的で使用される RabbitMQ vhost
ノード固有の hiera を使用して、同じブロックデバイスリストを持たない Ceph Storage ノードをデプロイすることができるようになりました。その結果、オーバクラウドデプロイメントの Heat テンプレート内でノード固有の hiera エントリーを使用して、類似していない OSD サーバーをデプロイすることができます。
今回の機能拡張により、OpenStack Bare Metal Provisioning サービス (ironic) をオーバークラウドにデプロイしてベアメタルインスタンスのデプロイメントをサポートできるようになりました。この機能はオーバークラウドにベアメタルインスタンスをデプロイする必要がある場合があるために追加されました。
その結果、Red Hat OpenStack Platform director はオプションで Bare Metal Provisioning サービスをデプロイしてオーバークラウドでベアメタルインスタンスをプロビジョニングできるようになりました。
今回の更新で、「リアルタイム」の機能が追加され、仮想 CPU で最悪の場合のスケジューラーのレイテンシーに対する保証が強化されました。この更新は、CPU 実行のレイテンシーに関するワークロードを実行する必要があり、リアルタイムの KVM ゲストの設定によって提供される保証を必要とするテナントを補助します。
Telemetry API (ceilometer-api) はイベントレットの代わりに apache-wsgi を使用するようになりました。本リリースにアップグレードする際には、ceilometer-api が適切に移行されます。

今回の変更によりデプロイメントごとのパフォーマンスとスケーリングの調整における柔軟性が向上し、SSL の使用が簡単になりました。
今回の機能拡張により、仮想デバイスロールのタグ付けがサポートされるようになりました。この機能は、インスタンスのオペレーティングシステムに、そのインスタンスを実行している仮想デバイスについての追加情報が必要な場合があるために追加されました。たとえば、複数のネットワークインターフェースのあるインスタンスでは、適切にプロビジョニングするために、ゲストのオペレーティングシステムの用途を区別する必要があります
今回の更新で、仮想デバイスロールのタグ付けにより、ユーザーはインスタンスの作成時に、仮想デバイスにタグを付けられるようになりました。これらのタグは、メタデータ API を使用して、コンフィグドライブ (有効化されている場合) を介して (他のデバイスメタデータとともに) インスタンスに提示されます。詳しい情報は、『Red Hat OpenStack Platform 10 ネットワークガイド』の「Use Tagging for Virtual Device Identification」の章を参照してください: https://access.redhat.com/documentation/en/red-hat-openstack-platform/
今回の更新により、OpenStack でのコンテナー使用のテストに必要なコンポーネントが含まれるようになりました。この機能は本リリースではテクノロジープレビューとして提供されています。
Gnocchi 2.2 では、ジョブのディスパッチは Redis を使用してコントローラー間で調整されるようになったため、Telemetry の計測値の処理の改善を期待できるようになりました。
コンポーザブルサービスに対応するために、Image サービス (glance) バックエンドとして使用する NFS マウントは Pacemaker によって管理されなくなったため、glance NFS バックエンドパラメーターのインターフェースが変更され、新しいメソッドでは環境ファイルを使用して NFS バックエンドを有効化するようになりました。以下に例を示します。
----
parameter_defaults:
  GlanceBackend: file
  GlanceNfsEnabled: true
  GlanceNfsShare: IP:/some/exported/path
----
注記: GlanceNfsShare の設定はデプロイメントによって異なります。
また、「GlanceNfsOptions」パラメーターを使用してマウントオプションをカスタマイズすることができます。Glance NFS バックエンドを以前 Red Hat OpenStack Platform 9 で使用していた場合には、環境ファイルの内容を更新して、Red Hat OpenStack Platform 10 の書式と一致するようにする必要があります。
現在、ネットワークの設定を変更するとインターフェースが再起動して、オーバークラウドノード上のネットワーク接続が中断されるという既知の問題があります。そのため、ネットワークの中断によって、Pacemaker コントローラークラスター内でサービスが停止し、ノードがフェンシングされてしまいます (フェンシングが設定されている場合)。その結果、tripleo-heat-templates はオーバークラウドの更新時にネットワーク設定の変更を適用しないように設計されています。ネットワークの変更を適用しないことによって、意図せずにクラスターのサービスが停止してしまうことを避けます。
現在、特定の設定ステップでは、オーバークラウドコントローラーに SSH 接続する必要があり、オーバークラウドノードに到達するには、仮想 IP を通過する必要があります。
お使いの環境で外部のロードバランサーを使用している場合には、このステップで接続は成功しない可能性が高くなります。この問題を回避するには、外部のロードバランサーがポート 22 を転送するように設定すると、仮想 IP へ正常に SSH 接続できるようになります。
controller_v6.yaml テンプレートには、管理ネットワークの VLAN 用のパラメーターが 1 つ含まれています。このパラメーターは、現在のバージョンの director ではサポートされていないので、管理ネットワークに関する他のコメントとともに無視しても安全です。管理ネットワークの参照は、カスタムテンプレートにコピーする必要はありません。

このパラメーターは将来のバージョンでサポートされる予定です。
director はデプロイメントの前または実行中にネットワークの検証を提供しません。そのため、ネットワーク設定が適切でないデプロイメントが数時間実行されて、何も出力が表示されずに結果的に失敗する可能性があります。ネットワーク検証のスクリプトは現在開発中で、将来のリリースで実装される予定です。
今回のリリースでは、Red Hat OpenStack Platform director は、コントローラーノード 3 台で構成される高可用性 (HA) のオーバークラウドデプロイメントのみをサポートしています。
現在、director がパブリック API に接続して最終の設定のデプロイ後のステップを完了するのに必要となる既知の要件があります。この要件は、アンダークラウドノードにはパブリック API へのルートが 1 つあることと、そのルートが標準の OpenStack API ポートおよびポート 22 (SSH) で到達可能である必要があることです。
この要件に対応するには、デプロイ後のタスクで使用するコントローラー上の外部ネットワークにアンダークラウドが到達可能かをチェックしておいてください。このような準備をしておくことにより、アンダークラウドはデプロイ後にパブリック API に正常に接続して、最終の設定タスクを実行することができます。これらのタスクは、admin アカウントを使用して新規作成したデプロイメントを管理するのに必要です。
NovaEnableRbdBackend パラメーターを使用する場合には、一時ストレージが true としてハードコードされています。これは、NovaEnableRbdBackend インスタンスが Ceph Storage 上に cinder バックエンドを使用できないことを意味します。回避策として、以下の行を puppet/hieradata/compute.yaml に追加します。

nova::compute::rbd::ephemeral_storage: false

これで一時ストレージが無効になります。
openstack-cinder-volume が LVM バックエンドの使用時にオーバークラウドノードが再起動すると、ファイルベースのループバックデバイスは再度作成されません。回避策として、ループバックデバイスを手動で再作成します。

$ sudo losetup /dev/loop2 /var/lib/cinder/cinder-volumes

次に、openstack-cinder-volume を再起動します。openstack-cinder-volume はオーバークラウドコントローラーノードの高可用性クラスター内では、1 回に 1 つのノードでしか実行できません。ただし、ループバックデバイスは、全ノード上に存在します。
Red Hat OpenStack Platform director のデプロイ時には、bare-metal ノードの電源はオフにして、ironic で「node-state」と「provisioning-state」が正しい必要があります。
たとえば、ironic がノードを「Available, powered-on」で表示されていても、サーバーが実際には電源がオフの状態である場合には、そのノードはデプロイメントには使用できません。
そのため、ironic でのノードの状態と実際のノードの状態を一致させる必要があります。「ironic node-set-power-state <node> [on|off]」と「ironic node-set-provisioning-state <node> available」のいずれか一方または両方を使用して、ironic 内での電源状態がサーバーの実際の状態と一致するようにして、ノードが「Available」とマークされるようにします。
その結果、ironic でのノードの状態が正しくなった後には、ironic は電源状態を正しく管理して、ノードをデプロイできるようになります。
IBM x3550 M5 サーバーには、Red Hat OpenStack Platform で機能する最小限のバージョンのファームウェアが必要です。 
そのため、ファームウェアのレベルが古い場合には、デプロイメントの前にアップグレードする必要があります。影響を受けるシステムは、次のバージョン (またはそれ以降のバージョン) にアップグレードする必要があります。
DSA 10.1, IMM2 1.72, UEFI 1.10, Bootcode NA, Broadcom GigE 17.0.4.4a 

ファームウェアのアップグレード後には、デプロイメントは想定通りに進めることができるはずです。
puppet のマニフェストのバグが原因で、アンダークラウドのインストールプロセス中に LVM パーティションの自動マウントが誤って無効化されていました。その結果、root および swap 以外のパーティションを使用する (カーネルコマンドラインでアクティブ化された) アンダークラウドホストは、緊急シェルでしかブートできない可能性がありました。

この問題を回避するには、複数の方法があります。以下のいずれかを選択してください。

1. /etc/fstab からマウントポイントを手動で削除します。この方法は、今後いかなる場合においても問題が生じることを防ぐことができます。他のパーティションを削除して、別のパーティション (root または swap) にスペースを追加することも可能です。

2. アクティブ化するパーティションを /etc/lvm.conf で設定します。この方法は、次回の更新/アップグレードでアンダークラウドのインストールが再実行されるまで機能します。

3. 初回のデプロイメントを root と swap パーティションに限定します。この方法は、問題を完全に回避することができます。
Red Hat Ceph を永続ストレージ用バックエンドとして使用する場合には、Compute サービスは利用可能なストレージ容量を正しく計算しません。厳密に言うと、Compute がレプリケーションを考慮に入れず、単に利用可能なストレージを加算してしまいます。その結果、利用可能なストレージ容量は実際の容量を大幅に上回る値が提示され、予期しないストレージオーバーサブスクリプションが発生してしまう可能性があります。

一時ストレージの正しい容量を確認するには、代わりに Ceph サービスに対して直接クエリーを実行してください。
「tuned」プロファイルがアクティブ化された後には、「openvswitch」サービスよりも前に「tuned」サービスを起動して、PMD に割り当てられるコアが正しく設定されるようにする必要があります。

回避策として、以下のスクリプトを実行して 「tuned」サービスを変更することができます。

#!/bin/bash

tuned_service=/usr/lib/systemd/system/tuned.service

grep -q "network.target" $tuned_service
if [ "$?" -eq 0 ]; then
  sed -i '/After=.*/s/network.target//g' $tuned_service
fi

grep -q "Before=.*network.target" $tuned_service
if [ ! "$?" -eq 0 ]; then
  grep -q "Before=.*" $tuned_service
  if [ "$?" -eq 0 ]; then
    sed -i 's/^\(Before=.*\)/\1 network.target openvswitch.service/g' $tuned_service
  else
    sed -i '/After/i Before=network.target openvswitch.service' $tuned_service
  fi
fi

systemctl daemon-reload
systemctl restart openvswitch
exit 0
現在、「Instance.pci_devices」フィールドでは NULL 値を指定可能ですが、「get_instance_pci_devs()」関数はその可能性を許可していません。旧デプロイメント (例: Red Hat OpenStack Platform 9) からインスタンスに渡される場合には「pci_devices」の値が指定されていないと、「None」をリストとして反復を試みてクラッシュします。
この問題の対象範囲には、アップグレードのワークフローの一環としてトリガーされるライブマイグレーションが含まれ、Red Hat OpenStack Platform 9 ホストから Red Hat OpenStack Platform 10 ホストにゲストのライブマイグレーションを試みます。
この問題を解決するためのパッチは特定済みで、Red Hat のお客様にはエラータとして リリースされる予定です。既存インスタンスをライブマイグレーションする方法でローリングアップグレードを予定しているお客様は、このエラータが提供されるまでアップグレードを見合わせることを推奨します。
Red Hat Enterprise Linux 6 には GRUB Legacy のみが含まれていますが、OpenStack Bare Metal Provisioning サービス (ironic) は GRUB2 のインストールのみをサポートしているため、ローカルブートでパーティションイメージをデプロイすると、ブートローダーのインストール中にエラーが発生します。
回避策としては、ベアメタルインスタンスに RHEL 6 を使用する場合には、フレーバーの設定で、boot_option を local に設定しないようにします。GRUB Legacy がインストール済みの RHEL 6 ディスクイメージ全体をデプロイすることも検討することができます。
Ceph と LVM 専用のブロックストレージノードを使用する Red Hat OpenStack 10 環境をデプロイ/アップグレードすると、ボリュームがアタッチされたインスタンスの作成は機能しなくなります。この問題は、director がアップグレード中に Block Storage サービスを設定する方法にバグがあることが原因です。 

具体的には、Heat テンプレートはデフォルトでは、Ceph と専用のブロックストレージノードを併せて設定するユースケースは考慮されていないため、director は一部の必要な設定の定義に失敗してしまいます。

LVM は、特にエンタープライズ環境の実稼働用の Block Storage バックエンドには適していない点に注意してください。

この問題は回避するには、以下の内容を記載した環境ファイルをアップグレードまたはデプロイメントに追加してください。

parameter_defaults:
  BlockStorageExtraConfig:
    tripleo::profile::base::cinder::volume::cinder_enable_iscsi_backend: true
    tripleo::profile::base::cinder::volume::cinder_enable_rbd_backend: false
オーバークラウドのイメージに、バージョン 2.7.1-4 未満の 「tuned」 が同梱されている場合には、「tuned」 パッケージの更新をそのオーバークラウドに手動で適用する必要があります。「tuned」バージョンが 2.7.1-4 以降の場合には、「tuned」にコアの一覧を提供してプロファイルをアクティブ化する必要があります。以下に例を示します。

# echo "isolated_cores=2,4,6,8,10,12,14,18,20,22,24,26,28,30" >> /etc/tuned/cpu-partitioning-variables.conf
# tuned-adm profile cpu-partitioning
以前のバージョン (Red Hat Ceph Storage 1.3) を使用する外部の Ceph Storage クラスターと統合された Red Hat OpenStack Platform 環境をアップグレードまたはデプロイする場合には、後方互換性を有効にする必要があります。そのためには、以下のスニペットを記載した環境ファイルをアップグレードまたはデプロイメントに追加します。

parameter_defaults:
  ExtraConfig:
    ceph::conf::args:
      client/rbd_default_features:
        value: "1"
ユーザー空間データパス (DPDK) を使用する場合には、一部の非 PMD スレッドは PMD を実行するのと同じ CPU 上で実行されます (「pmd-cpu-mask」で設定されます)。これは、PMD が割り込みされ、レイテンシースパイクやドロップなどが発生する原因となります。

今回の更新では post-install.yaml ファイルの修正が実装されました。このファイルは https://access.redhat.com/documentation/en/red-hat-openstack-platform/10/single/network-functions-virtualization-configuration-guide/#ap-ovsdpdk-post-install に記載されています。
Ceph Storage ノードは、「ext4」でフォーマットされたローカルのファイルシステムを「ceph-osd」サービスのバックエンドとして使用していました。

注記: Red Hat OpenStack Platform 9 (Mitaka) の「overcloud-full」イメージの一部は「xfs」の代わりに「ext4」を使用して作成されていました。

Jewel リリースでは「ceph-osd」が、バックエンドで許可されているファイル名の最大長を確認して、Ceph 自体で設定されている上限よりも低い場合には拒否します。回避策として、Ceph Storage ノードにログインして以下のコマンドを実行すると、「ceph-osd」に使用中のファイルシステムを確認することができます。

  # df -l --output=fstype /var/lib/ceph/osd/ceph-$ID

ここで $ID は OSD ID です。以下に例を示します。

  # df -l --output=fstype /var/lib/ceph/osd/ceph-0

注記: 単一の Ceph Storage ノードは、複数の「ceph-osd」インスタンスをホストしている可能性があり、その場合には、複数のサブディレクトリーが各インスタンスの「/var/lib/ceph/osd/」に存在することになります。

OSD インスタンスの*いずれか*が「ext4」ファイルシステムでバッキングされている場合には、Ceph が短いファイル名を使用するように設定する必要があります。これは、以下の内容を記載した追加の環境ファイルをデプロイ/アップグレードすることによって設定することができます。

  parameter_defaults:
    ExtraConfig:
      ceph::profile::params::osd_max_object_name_len: 256
      ceph::profile::params::osd_max_object_namespace_len: 64

その結果、Red Hat OpenStack Platform 9 から Red Hat OpenStack Platform 10 へのアップグレード後に、各「ceph-osd」インスタンスが稼働しているかどうかを確認できるようになります。
Open vSwitch、仮想マシンの CPU または仮想マシン内の VNF スレッドの実行中に、割り当てられた CPU への割り込みをできるだけ少なくするためには、CPU を分離すべきです。ただし、CPUAffinity は、全カーネルスレッドがこれらの CPU 上で実行されないようにすることはできません。大半のカーネルスレッドを防ぐには、ブートオプション 'isolcpus=<cpulist>' を使用する必要があります。これには 'nohz_full' および 'rcu_nocbs' と同じ CPU リストが使用されます。'isolcpus' はカーネルブート時に使用され、多数のカーネルスレッドが CPU 上でスケジュールされるのを防ぐことができます。これは、ハイパーバイザーとゲストサーバーの両方で実行することが可能です。

#!/bin/bash
isol_cpus=`awk '{ for (i = 1; i <= NF; i++) if ($i ~ /nohz/) print $i };'
/proc/cmdline | cut -d"=" -f2`

if [ ! -z "$isol_cpus" ]; then
  grubby --update-kernel=grubby --default-kernel --args=isolcpus=$isol_cpus
fi

2) 以下のスニペットは、エミュレータースレッドのアクションを再度固定するので、パフォーマンス上の特定の問題が発生した場合以外は使用することをお勧めしません。 

#!/bin/bash
cpu_list=`grep -e "^CPUAffinity=.*" /etc/systemd/system.conf | sed -e 's/CPUAffinity=//' -e 's/ /,/'`
 if [ ! -z "$cpu_list" ]; then
   virsh_list=`virsh list| sed -e '1,2d' -e 's/\s\+/ /g' | awk -F" " '{print $2}'`
     if [ ! -z "$virsh_list" ]; then
       for vm in $virsh_list; do virsh emulatorpin $vm --cpulist $cpu_list; done
     fi
 fi
「openstack baremetal import --json instackenv.json」を使用してインポートしたノードは、インポートを試みる前に電源をオフにする必要があります。ノードの電源がオンの場合には、Ironic はノードの追加やイントロスペクションを試みません。
この回避策として、「openstack baremetal import --json instackenv.json」を実行する前に全オーバークラウドノードの電源をオフにすることができます。
その結果、ノードの電源がオフになっている場合にはインポートが正常に機能するはずです。
DHCP HA を使用する場合には、コンポーザブルロールを使用して、「NeutronDhcpAgentsPerNetwork」の値を  dhcp-agent 数に等しい値または 3 のいずれか低い方に設定すべきです。このように設定しなかった場合には、この値はデフォルトで「ControllerCount」に設定され、各ネットワークで多数の DHCP サーバーの起動に対応するために dhcp-agent 数が十分でない場合があるために最適ではありません。
「AllocationPools」IPv6 ネットワークおよび IP の割り当てプールに入力するアドレス範囲は、RFC 5952 に従って有効な形式で入力する必要があります。エントリーが不完全だと機能せず、無効なエントリーによりエラーが発生します。
そのため、IPv6 アドレスは有効な形式で入力する必要があります。ゼロが繰り返される場合には「::」に置き換えることができます。
たとえば、「fd00:0001:0000:0000:00a1:00b2:00c3:0010」という IP アドレスは、「fd00:1::a1:b2:c3:10」と示すことができますが、「fd00:01::0b2:0c3:10」には無効な先頭ゼロ (01, 0b2, 0c3) が含まれているので使用できません。このフィールドでは、先頭のゼロを切り捨てるか、完全に埋め込む必要があります。
Glance で、glance.store.http.Store は、/etc/glance/glance.conf に known_store として設定されていないため、Glance クライアントで --copy-from 引数を使用してイメージを作成することはできません。このコマンドを実行すると、「400 Bad Request」エラーが表示されて操作が失敗します。回避策として、/etc/glance/glance-api.conf を編集して、「store」設定オプションのリストに glance.store.http.Store を追加してから、openstack-glance-api サーバーを再起動します。これにより、--copy-from 引数を使用した Glance イメージの作成を正常に実行できるようになります。
「openstack overcloud update stack」コマンドは、背後で操作が継続するにもかかわらず、即時に出力を返していました。このコマンドは対話的でないため、永遠に実行されるように見えました。そのような場合には、「-i」のフラグを付けてコマンドを実行すると、手動での対話が必要な場合にユーザーにプロンプトが表示されるようになります。
タイミングの問題により、オーバークラウドの neutron サービスは正しく自動起動しません。これは、インスタンスがアクセスできないことを意味します。回避策として、コントローラーノードクラスターで以下のコマンドを実行することができます。

$ sudo pcs resource debug-start neutron-l3-agent

これでインスタンスが適切に起動するようになります。
Red Hat OpenStack Platform 9 の時点で、nova-network のサポートは非推奨となり、将来のリリースでは削除される予定となっています。新規環境の作成時には、OpenStack Networking (Neutron) を使用することを推奨します。
特定の CLI の引数は非推奨と見なされており、使用すべきではありません。今回の更新では、それらの CLI の引数を使用することは可能ですが、少なくとも 1 つの環境ファイルを指定して、「sat_repo」を設定する必要があります。この問題を回避するには、overcloud コマンドを実行する前に、「env」ファイルを使用することができます。

1. cp -r /usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration  . 

2. rhel-registration/environment-rhel-registration.yaml を編集し、お使いの環境に応じて rhel_reg_org, rhel_reg_activation_key、rhel_reg_method、rhel_reg_sat_repo、および rhel_reg_sat_url を設定します。

3. -e rhel-registration/rhel-registration-resource-registry.yaml -e rhel-registration/environment-rhel-registration.yaml のオプションを指定してデプロイのコマンドを実行します。

この回避策は Red Hat Satellite 5 と 6 の両方で確認済みで、デプロイメントが成功すると、リポジトリーがオーバークラウドノードに設定されます。
アップストリームのプロジェクトに従って、LBaaS v1 API は削除され、Red Hat OpenStack Platfom 10 では LBaaS v2 API のみがサポートされています。
以前のリリースでは、instack-undercloud はサブネットマスクが「local_ip」パラメーターに指定されていることを検証しなかったため、誤って /32 マスクが使用されていました。そのため、このような状況ではアンダークラウドでネットワークが正しく機能しませんでした (例: イントロスペクションが機能しないなど)。今回の更新により、instack-undercloud は正しいサブネットマスクが指定されていることを検証するようになりました。
今回の更新の以前は、期限切れのトークンを Identity サービス (keystone) のデータベースから定期的に削除するための自動プロセスがありませんでした。そのため、keystone のデータベースが拡大し続けて膨大なサイズとなり、ディスクスペースをすべて使い果たしてしまう可能性がありました。
今回の更新により、keystone データベースに対して定期クエリーを 1 日に 1 回実行し、期限切れのトークンを削除するための crontab エントリーが追加されました。その結果、期限切れのトークンによって keystone データベースのサイズが無制限に拡大してしまうことはなくなりました。
以前のリリースでは、Bare Metal Provisioning サービス (ironic) の「pxe_ilo」ドライバーは UEFI 対応のハードウェアを検出すると、環境で UEFI がサポートされていない場合でも自動的に UEFI ブートに切り替えていました。
そのため、環境が UEFI をサポートしていない場合には、pxe_ilo ドライバーを使用するとデプロイメントプロセスが失敗していました。
今回の更新により、pxe_ilo ドライバーはデフォルトで BIOS ブートモードに設定され、pxe_ilo を使用したデプロイメントは、UEFI が適切に設定されているかどうかに拘らず、追加の設定なしに正常に機能するようになりました。
puppet のマニフェストのバグが原因で、アンダークラウドのインストールプロセス中に LVM パーティションの自動マウントが誤って無効化されていました。その結果、root および swap 以外のパーティションを使用する (カーネルコマンドラインでアクティブ化された) アンダークラウドホストは、緊急シェルでしかブートできない可能性がありました。

この問題を回避するには、複数の方法があります。以下のいずれかを選択してください。

1. /etc/fstab からマウントポイントを手動で削除します。この方法は、今後いかなる場合においても問題の発生を防ぐことができます。他のパーティションを削除して、別のパーティション (root または swap) にスペースを追加することも可能です。

2. アクティブ化するパーティションを /etc/lvm.conf で設定します。この方法は、次回の更新/アップグレードでアンダークラウドのインストールが再実行されるまで機能します。

3. 初回のデプロイメントを root と swap パーティションに限定します。この方法は、問題を完全に回避することができます。
以前のリリースでは、director により自動生成される「readonly_user_name」(/etc/ceilometer/ceilometer.conf) の値が 32 文字を超えていました。その結果、アップグレード中に ValueSizeConstraint エラーが発生していました。今回のリリースでは、director がデフォルトで「readonly_user_name」を「ro_snmp_user」に設定し、文字数制限が順守されるようになりました。
以前のリリースでは、swift のプロキシーパイプラインの設定が誤っていたため、swift のメモリー使用量は、swift が強制終了されるまで拡大し続けていました。今回の修正により、swift のプロキシーパイプラインの早期に proxy-logging が設定され、swift のメモリー使用量は拡大し続けないようになりました。
Red Hat Enterprise Linux 7.3 では、シェルスクリプトで使用される「systemctl is-enabled」コマンドが返す出力の形式が変更されたため、mariadb-galera RPM パッケージのインストール時には、MariaDB サービスが実際には有効化されていない場合でも有効化されているものとして誤って検出されていました。その結果、Red Hat OpenStack Platform のインストーラーは、systemd ではなく Pacemaker を使用して mariadb-galera の実行を試みるため、Galera の起動に失敗していました。今回の更新により、mariadb-galera の RPM インストールスクリプトは異なる systemctl コマンドを使用するようになり、デフォルトの MariaDB が無効化されているものとして正しく検出されて、インストーラーを正常に実行できるようになりました。
以前のリリースでは、「mariadb-server」と「mariadb-galera-server」の両方のパッケージに、クライアントで使用するライブラリー (「dialog.so」と「mysql_clear_password.so」) が同梱されていました。その結果、「mariadb-galera-server」のパッケージは、パッケージの競合によりインストールに失敗していました。

今回の更新では、「dialog.so」と「mysql_clear_password.so」のライブラリーは「mariadb-galera-server」から「mariadb-libs」に移動されたため、「mariadb-galera-server」パッケージは正常にインストールできるようになりました。
Gnocchi 2.2 では、ジョブのディスパッチは Redis を使用してコントローラー間で調整されるようになったため、Telemetry の計測値の処理の改善を期待できるようになりました。
今回の更新の以前は、Heat は「FloatingIP」リソースが実際にはまだ削除中であるのに、削除済みと見なす場合がありました。そのため、「FloatingIP」はまだ存在しているので、「FloatingIP」が依存するリソースの削除が失敗することがありました。
今回の更新で、Heat はリソースが削除されたものと見なす前に「FloatingIP」が存在しないことを確認するようになり、スタックの削除は正常に続行されるはずです。
以前のリリースでは、「str_replace」組み込み関数は、置き換える各文字列に対して Python「str.replace()」メソッドを呼び出すことによって機能していました。そのため、ある置換の置換テキストに、置換すべき別のテキストが含まれている場合には、置換テキスト自体が置き換えられてしまう場合がありました。置き換えの順序は保証されなかったので、結果が不明確となっていました。そのため、ユーザーはガード文字列などのテクニックの使用には注意を払って、誤解がないようにする必要があります。
今回の更新により、置き換えは単一パスで実行され、元のテキストのみが置き換えの対象となるようになりました。
その結果、「str_replace」の出力は明確となり、ガード文字列を使用しない場合でも、ユーザーの想定と一致するようになりました。入力でキーが重複した場合には、一致がより長い方が優先され、あいまいさが依然としてある場合には、辞書学上短い文字列が最初に置き換えられます。
今回の機能拡張により、「heat-manage」が「heat-manage reset_stack_status」サブコマンドをサポートするようになりました。このサブコマンドは、「heat-engine」がデータベースと通信できないために、進行中のスタックがそのままで停止してしまう状況に対応するために追加されました。この問題が発生した場合には、管理者がステータスをリセットして、スタックが再度更新できるようにする方法が必要でした。
この機能が拡張された結果、管理者は「heat-manage reset_stack_status」コマンドで進行中の状態で停止したスタックをリセットすることができるようになりました。
今回の更新により、IPMItool ドライバー向けに socat ベースのシリアルコンソールが追加されました。これは、ユーザーが仮想ノードのコンソールにアクセスするのと同じ方法でベアメタルノードのシリアルコンソールにアクセスする必要がある場合があるために追加されました。その結果、新しいドライバー「pxe_ipmitool_socat」が追加され、「socat」ユーティリティーを使用したシリアルコンソールがサポートされるようになりました。
Bare Metal Provisioning サービスは、パーティショニングおよびイメージの書き込みを実行する前に、ディスクのメタデータをワイプするようになりました。これにより、新規イメージは通常どおりに起動します。以前のリリースでは、Bare Metal Provisioning サービスは、デバイスで操作を開始する前に、古いメタデータを削除しなかったため、デプロイが失敗することがありました。
openstack-ironic-conductor サービスは、「enabled_drivers」オプションで指定されている全ドライバーが一意かどうかを確認するようになりました。このサービスは、重複したエントリーを削除して、警告をログに記録します。以前のリリースでは、「enabled_drivers」オプションで重複したエントリーがある場合には単に openstack-ironic-conductor サービスでエラーが発生していたため、Bare Metal Provisioning サービスはドライバーをロードすることができませんでした。
以前のリリースでは、「ironic-conductor」は「python-neutronclient」に対して認証トークンを正しく渡しませんでした。その結果、自動ノードクリーニングで切断のエラーが発生していました。

今回の更新により、OpenStack Bare Metal Provisioning サービス (ironic) は、直接 Identity サービスのクライアントオブジェクトを構築するのではなく、「keystoneauth」セッションを使用するように移行されました。その結果、ノードはクリーニングの後に正常に切断できるようになりました。
デプロイ中のノードを特定するには、デプロイ用 ramdisk (IPA) が Bare Metal Provisioning サービスにそのノードの一意識別子として MAC アドレスの一覧を提供します。以前のリリースでは、Bare Metal Provisioning サービスは通常の MAC アドレス形式 (6 オクテット) のみを想定していましたが、Infiniband NIC の GID は 20 オクテットであるため、Infiniband NIC がノードで提示されると、Bare Metal Provisioning API は MAC アドレスを正しく検証できなかったため、デプロイは失敗していました。

今回のリリースで。Bare Metal Provisioning サービスは通常の 6 オクテットの形式に準拠しない MAC アドレスを無視するようになりました。
今回のリリースでは、不必要な「dhcp」コマンドがデプロイメント/イントロスペクション用の iPXE テンプレートから削除されました。場合によっては、この不要なコマンドによって IP アドレスを受信するために誤ったインターフェースが使用されていました。
以前のリリースでは、tarfile の作成時に、IPA RAM ディスクのログに変更日が設定されていませんでした。その結果、イントロスペクションログに変更日が 1970-01-01 と記録されていたため、ファイルの抽出時に GNU tar が警告を表示していました。 

今回の更新により、tarfile の作成時には変更日が適正に設定されるようになりました。タイムスタンプは正しく記録され、GNU tar は警告を表示しなくなりました。
今回のリリースは、より徹底したエラーチェックと LLDP 検出に関連する処理を特徴としています。この機能拡張は、無効なパッケージで LLDP の検出が失敗するのを防ぎます。また、LLDP の検出が失敗しても、イントロスペクションプロセス全体が失敗することはなくなりました。
今回の更新の以前は、CephFS ドライバーは、Ceph サーバーに接続可能かどうかをチェックしませんでした。
そのため、Ceph サーバーへの接続が機能しない場合には、「manila-share」サービスはタイムアウトせずにクラッシュまたは再起動を繰り返していました。
今回の更新により、Manila CephFS ドライバーの初期時に Ceph への接続を確認するチェックが行われるようになりました。その結果、Ceph ドライバーはドライバーの初期化時に Ceph の接続を確認し、接続に失敗した場合には、ドライバーは初期化されず、それ移行のステップは実行されないようになりました。
以前のリリースでは、WSGI サーバーによって随時に開くことのできるクライアント接続の最大数 (1 回に起動する greenlets の数) は、「wsgi_default_pool_size」で 100 に設定されていました。この設定は OpenStack Networking API サーバーには適切でしたが、状態変更サーバーにより、L3 エージェントにおける CPU の負荷が高くなり、エージェントがクラッシュする原因となっていました。

今回のリリースでは、新たな「ha_keepalived_state_change_server_threads」設定を使用して状態変更サーバーのスレッド数を設定することができます。クライアントの接続は、「wsgi_default_pool_size」により限定されなくなり、状態変更サーバーのスレッドが多数起動した際に、L3 エージェントがクラッシュしないようになりました。
以前のリリースでは、「vport_gre」カーネルモジュールは Red Hat Enterprise Linux 7.3 の「ip_gre」カーネルモジュールに依存していました。「ip_gre」モジュールは、「gre0」および「gretap0」という 2 つの新しいインターフェースを作成していました。これらのインターフェースは名前空間ごとに作成され、削除はできませんでした。その結果、「neutron-netns'cleanup」が名前空間のクリーンアップ中に全インターフェースを削除する際に「gre0」と「gretap0」は削除できませんでした。そのため、インターフェースが残っていることが原因でネットワーク名前空間が削除できませんでした。 

今回の更新により、「gre0」と「gretap0」のインターフェースはインターフェースのホワイトリストに追加され、名前空間にインターフェースがあるかどうかをチェックする際には無視されるようになりました。その結果、ネットワークの名前空間に「gre0」と「gretap0」のインターフェースが含まれている場合でも、その名前空間は削除されるようになりました。
今回のリリースでは、OpenStack Networking API の前に HTTPProxyToWSGI ミドルウェアが追加され、クライアントとサーバーの間でプロキシー (例: HAProxy) が使用されている場合に要求 URL を正しく設定するようになりました。これにより、クライアントが SSL を使用する場合には、サーバーがこれを認識して、正しいプロトコルを使用して応答します。以前のリリースでは、プロキシーを使用すると、クライアントが SSL を使用している場合でも、サーバーは (HTTPS の代わりに) HTTP を使用して応答が可能でした。
以前のリリースでは、OpenStack Networking の OVS エージェントは、サブプロセスが適切に実行されなかった場合に、翻訳されていない文字列を翻訳済みの UTF-16 の文字列と比較していました。英語以外のロケールでは、これにより例外が発生し、インスタンスが起動できなくなっていました。

この問題に対処するために、文字列ではなく失敗したサブプロセスで実際に戻り値に応じてエラーチェックが行われるように更新されました。これにより、英語以外のロケールでも、サブプロセスのエラーが適切に処理されるようになりました。
今回の更新で、IP トラフィックは QoS ポリシーにアタッチされた DSCP マーキングルールによって管理できるようになりました。このポリシーは、ネットワークとポートに適用されます。
これは、特にリアルタイムの情報やクリティカルな制御データを処理する場合に、トラフィックソースによって、ネットワークレベルで必要とされる優先順位のレベルが異なる場合があるために追加されました。その結果、特定のポートとネットワークからのトラフィックは DSCP フラグでマークすることができるようになりました。本リリースでは、Open vSwitch のみがサポートされている点に注意してください。
今回の機能拡張により、仮想デバイスロールのタグ付けがサポートされるようになりました。この機能は、インスタンスのオペレーティングシステムに、そのインスタンスを実行している仮想デバイスについての追加情報が必要な場合があるために追加されました。たとえば、複数のネットワークインターフェースのあるインスタンスでは、適切にプロビジョニングするために、ゲストのオペレーティングシステムの用途を区別する必要があります。
今回の更新で、仮想デバイスロールのタグ付けにより、ユーザーはインスタンスの作成時に、仮想デバイスにタグを付けられるようになりました。これらのタグは、メタデータ API を使用して、コンフィグドライブ (有効化されている場合) を介して (他のデバイスメタデータとともに) インスタンスに提示されます。詳しい情報は、『Red Hat OpenStack Platform 10 ネットワークガイド』の「Use Tagging for Virtual Device Identification」の章を参照してください: https://access.redhat.com/documentation/en/red-hat-openstack-platform/
今回の更新で、「リアルタイム」の機能が追加され、仮想 CPU で最悪の場合のスケジューラーのレイテンシーに対する保証が強化されました。この更新は、CPU 実行のレイテンシーに関するワークロードを実行する必要があり、リアルタイムの KVM ゲストの設定によって提供される保証を必要とするテナントを補助します。
今回の機能拡張により、仮想デバイスロールのタグ付けがサポートされるようになりました。この機能は、インスタンスのオペレーティングシステムに、そのインスタンスを実行している仮想デバイスについての追加情報が必要な場合があるために追加されました。たとえば、複数のネットワークインターフェースのあるインスタンスでは、適切にプロビジョニングするために、ゲストのオペレーティングシステムの用途を区別する必要があります。
今回の更新で、仮想デバイスロールのタグ付けにより、ユーザーはインスタンスの作成時に、仮想デバイスにタグを付けられるようになりました。これらのタグは、メタデータ API を使用して、コンフィグドライブ (有効化されている場合) を介して (他のデバイスメタデータとともに) インスタンスに提示されます。詳しい情報は、『Red Hat OpenStack Platform 10 ネットワークガイド』の「Use Tagging for Virtual Device Identification」の章を参照してください: https://access.redhat.com/documentation/en/red-hat-openstack-platform/
以前のリリースでは、nova ironic virt ドライバーは、デプロイメントが開始する前にインスタンスの UUID を Bare Metal Provisioning (ironic) ノードに書き込んでいました。UUID の書き込みとデプロイメントの起動の間に何らかのエラーが発生した場合に、Compute はインスタンスの起動に失敗した後でもそのインスタンスを削除しませんでした。その結果、Bare Metal Provisioning (ironic) ノードには、インスタンスの UUID セットが残ってしまい、別のデプロイメントでは選択されませんでした。

今回の更新により、デプロイメントのいずれかの段階でインスタンスの起動が失敗すると、ironic virt ドライバーはインスタンスの UUID を確実にクリーンアップするようになりました。その結果、ノードにはインスタンスの UUID セットが残らず、新規デプロイメントに選択されるようになりました。
以前のリリースでは、director を使用してデプロイされた Object Storage サービスは Red Hat OpenStack Platform 8 (liberty) 以降で非推奨となっている ceilometer ミドルウェアを使用していました。

今回の更新で、Object Storage サービスは修正され、本リリースでサポートされている python-ceilometermiddleware からの ceilometer ミドルウェアを使用するようになりました。
以前のリリースでは、Time Series Database-as-a-Service (gnocchi) API ワーカーは、単一プロセスとスレッドの論理 cpu_core カウントを使用するデフォルトでデプロイされるよう設定されていたため、httpd で実行中の gnocchi API は単一プロセスでデプロイされていました。 

gnocchi では、ベストプラクティスとして、プロセス数とスレッド数を 1.5 * cpu_count に推奨しています。今回の更新で、ワーカーのカウントは max(($::processorcount + 0)/4, 2) となり、スレッドは 1 となりました。その結果、gnocchi API ワーカーは正しい数のワーカーとスレッドで実行されるようになり、パフォーマンスが向上しました。
以前のリリースでは、パッケージの更新で「DeployIdentifier」は更新されなかったため、コントローラー以外のノードで Puppet が実行されませんでした。 

今回の更新により、「DeployIdentifier」の値がインクリメントされ、Puppet はコントローラー以外のノードで実行され、パッケージを更新するようになりました。
以前のリリースでは、OpenStack director で、オペレーターがメジャーアップグレードの一環としてコントローラーノード以外のノードをアップグレードするためにアンダークラウドで使用する「upgrade-non-controller.sh」スクリプトは、「--query」オプションを使用した場合にアップグレードのステータスを報告しませんでした。その結果、「--query」は「-h」のヘルプテキストに記載されているとおりには機能しませんでした。 

今回の更新で、「--query」オプションを使用した場合に、アップグレードのステータスとしてそのノードの「yum.log」ファイルの末尾数行が表示されるようになりました。また、このスクリプトで、このオプションの長いバージョンと短いバージョンの両方 (「-q」と「--query」) が受け入れられるようになりました。その結果、「upgrade-non-controller.sh」スクリプトはノードのアップグレードステータスを少なくともある程度表示するように改善されました。
「openstack baremetal import --json instackenv.json」を使用してインポートしたノードは、インポートを試みる前に電源をオフにする必要があります。ノードの電源がオンの場合には、Ironic はノードの追加やイントロスペクションを試みません。
この回避策として、「openstack baremetal import --json instackenv.json」を実行する前に全オーバークラウドノードの電源をオフにすることができます。
その結果、ノードの電源がオフになっている場合にはインポートが正常に機能するはずです。
スタックデプロイメントの起動時に Heat の環境ファイルを使用して、オーバークラウドに「cinder-backup」をデプロイすることが可能となりました。「cinder-backup」を有効にするこの環境ファイルは、/usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml です。「cinder-backup」サービスは最初にバックエンドとして Swift または Ceph の使用をサポートします。「cinder-backup」サービスは、ボリュームの保管先とは異なるバックエンド上の Cinder ボリュームのバックアップを実行します。「cinder-backup」サービスは、デプロイ時に追加されている場合には、オーバークラウド内で実行されます。
今回の更新の以前には、RabbitMQ のオープンファイル記述子の最大値は 4096 に設定されていました。そのため、大型のデプロイメントを使用している場合にこの上限に達して、安定性で問題が生じる可能性がありました。今回の更新により、RabbitMQ のオープンファイル記述子の上限が 65536 に拡張されました。その結果、大型のデプロイメントでこの問題が発生する可能性が極めて低くなりました。
今回の機能拡張により、OpenStack Bare Metal Provisioning サービス (ironic) をオーバークラウドにデプロイしてベアメタルインスタンスのデプロイメントをサポートできるようになりました。この機能はオーバークラウドにベアメタルインスタンスをデプロイする必要がある場合があるために追加されました。
その結果、Red Hat OpenStack Platform director はオプションで Bare Metal Provisioning サービスをデプロイしてオーバークラウドでベアメタルインスタンスをプロビジョニングできるようになりました。
今回の更新により、オーバークラウドのコントローラーノード上の iptables ファイアウォールが有効化されてセキュリティーが強化されました。その結果、必要なポートが開放され、オーバークラウドは以前のとおりに機能し続けます。
今回の更新で、オーバークラウドからモニタリングインフラストラクチャーへの接続を有効にする新機能により、オーバークラウドノードに可用性管理エージェント (sensu-client) がデプロイされるようになりました。 

モニタリングエージェントのデプロイメントを有効にするには、「/usr/share/openstack/tripleo-heat-templates/environments/monitoring-environment.yaml」という環境ファイルを使用して、以下のパラメーターをその YAML 設定ファイルに指定します。

MonitoringRabbitHost: モニタリングを目的とする RabbitMQ インスタンスを実行するホスト
MonitoringRabbitPort: モニタリングを目的とする RabbitMQ インスタンスが実行されるポート
MonitoringRabbitUserName: RabbitMQ インスタンスに接続するためのユーザー名
MonitoringRabbitPassword: RabbitMQ インスタンスに接続するためのパスワード
MonitoringRabbitVhost: モニタリング目的で使用される RabbitMQ vhost
director を使用して Ceph RadosGW をオブジェクトストレージのゲートウェイとしてデプロイできるようになりました。そのためには、オーバークラウドのデプロイメントに /usr/share/openstack-tripleo-heat-templates/environmens/ceph-radosgw.yaml を追加します。この Heat テンプレートを使用する場合には、デフォルトの Object Storage サービス (swift) はデプロイされません。
通常、OpenStack における OVS+DPDK の設定は、オーバークラウドのデプロイ後に手動で実行されます。これは、多数のコンピュートノードが対象となる場合にはオペレーターにとって非常に困難で、退屈な作業となる可能性がありました。今回の更新により OVS+DPDK のインストールは tripleo で自動化されました。以前は手動で行われていた DPDK のハードウェア機能の特定は、イントロスペクション中に自動化されました。また、ハードウェアの検出により、Heat テンプレートの設定に必要な情報がオペレーターに提供されるようになりました。現在、DPDK 対応のハードウェアを搭載しているコンピュートノードと、DPDK 対応のハードウェアを搭載していないコンピュートノードを共存させることはできません。
「ironic」Python エージェントは以下のハードウェア情報を検出して swift のブロブに保管します。
* ヒュージページサポートの CPU フラグ: pse が存在する場合には 2 MB のヒュージページがサポートされ、pdpe1gb が存在する場合には 1 GB のヒュージページがサポートされます。
* IOMMU の CPU フラグ: VT-d/svm が存在する場合には IOMMU がサポートされます。ただし、BIOS で IOMMU サポートが有効化されていることが条件です。
* 互換性のある NIC: DPDK にホワイトリストされている NIC の一覧 (http://dpdk.org/doc/nics に記載) と対照します。

上記の機能のいずれも搭載されていないノードは、DPDK を使用するコンピュートの役割には使用できません。

* オペレーターは、コンピュートノードで DPDK を有効にするためのプロビジョニングを使用することができます。 
* コンピュート対応で DPDK NIC が搭載されていると確認されたノード向けのオーバークラウドイメージには、OVS の代わりに OVS+DPDK パッケージが使用されます。また、「dpdk」および「driverctl」のパッケージも含まれます。
* DPDK 対応の NIC のデバイス名は、T-H-T から取得されます。DPDK NIC の PCI アドレスは、デバイス名から識別される必要があります。これは、PCI のプロービング中に DPDK NIC をホワイトリストするのに必要です。
* ヒュージページは DPDK を使用するコンピュートノードで有効にする必要があります。
* DPDK Poll Mode Driver (PMD) に確保される CPU コアが一般のカーネルバランシングに使用されてアルゴリズムの処理とスケジューリングを中断しないようにするために、CPU を分離する必要があります。  
* DPDK を有効にした NIC を使用する各コンピュートノードでは、puppet によってホワイトリストされた NIC の DPDK_OPTIONS、CPU マスク、および DPDK PMD のメモリーチャネル数が設定されます。DPDK_OPTIONS は /etc/sysconfig/openvswitch で設定する必要があります。

「Os-net-config」は以下のステップを実行します。
* 指定したインターフェースの pci アドレスを特定することにより、そのインターフェースを dpdk ドライバー (デフォルトは vfio-pci ドライバー) に関連付けます。ドライバーを永続的にバインディングするために driverctl が使用されます。
* ovs_user_bridge と ovs_dpdk_port のタイプを理解して、ifcfg スクリプトを適切に設定してください。
* 「タイプ」ovs_user_bridge は OVS タイプ OVSUserBridge と解釈され、これに基づいて OVS がデータパスタイプを「netdev」に設定します。
* 「タイプ」 ovs_dpdk_port は OVS タイプ OVSDPDKPort と解釈され、これに基づいて OVS がインターフェースタイプを「dpdk」としてポートをブリッジに追加します。
* ovs_dpdk_bond を理解して ifcfg スクリプトを適切に設定します。

DPDK を有効にした NIC を使用する各コンピュートノードで puppet により以下のステップが実行されます。
* /etc/neutron/plugins/ml2/openvswitch_agent.ini [OVS] datapath_type=netdev vhostuser_socket_dir=/var/run/openvswitch での OVS+DPDK の有効化
* qemu により所有される /var/run/openvswitch での vhostuser ポートの設定

各コントローラーノードで puppet により以下のステップが実行されます。
* nova.conf で NUMATopologyFilter を scheduler_default_filters に追加します。

その結果、上記の機能拡張されたプラットフォームの認識の自動化が完了し、QA テストで検証されます。
今回のリリースは、コンポーザブルロールを特徴としており、TripleO はコンポーザブルな方法でデプロイ可能となりました。これにより、各ノードで実行する必要のあるサービスをユーザーが選択することができるので、複雑なユースケースをより多くサポートできます。
ハードウェアのプロビジョニング段階に汎用ノードをデプロイできるようになりました。これらのノードは、汎用オペレーティングシステム (Red Hat Enterprise Linux) を使用してデプロイされ、ユーザーはそれらのノードに直接、追加のサービスをデプロイすることができます。
https://bugs.launchpad.net/tripleo/+bug/1630247 に記載されているように、アップストリームの Newton TripleO では Sahara サービスがデフォルトで無効化されましたが、Red Hat OpenStack Platform 9 から Red Hat OpenStack Platform 10 へのアップグレード手順では、Sahara サービスはデフォルトで有効化/維持されます。アップグレード後に Sahara は不要であるとオペレーターが判断した場合には、コントローラーのアップグレードとコンバージステップのコマンドで「-e 'major-upgrade-remove-sahara.yaml'」の環境ファイルを指定する必要があります。この環境ファイルは、特にコンバージのステップで末尾に指定する必要がありますが、混乱を避けるために両方のステップで末尾に指定することができます。このオプションを指定すると、Sahara サービスはメジャーアップグレード後に再起動しなくなります。
この方法により、Sahara サービスは OSP9 から OSP10 へのアップグレード中に適切に処理されます。また現在も、必要な場合には、オペレーターは Sahara を明示的に無効にすることが可能です。
今回の更新により、KernelPidMax Heat パラメーターを使用して kernel.pid_max sysctl キーにカスタムの値を指定できるようになりました。デフォルト値は 1048576 です。Cephクライアントとして機能するノードでは、ceph-osd インスタンスの数に応じて多数のスレッドが実行される場合があります。そのような場合には、pid_max が最大値に達して、I/O エラーが発生する原因となる可能性があります。本リリースでは、pid_max キーのデフォルト値が高くなり、KernelPidMax パラメーターを使用したカスタマイズが可能となりました。
以前のリリースでは、サーバーのメタデータ取得には Orchestration サービスがポーリングされていたため、Compute への REST API コールが実行されて nova-api に持続的な負荷がかかり、クラウドがスケールアップするに従って悪化していました。 

今回の更新により、サーバーのメタデータには Object Storage サービスがポーリングされるようになったので、Heat スタックをロードするために nova-api に不要なコールは実行しなくなりました。その結果、オーバークラウドのスケールアップに伴うアンダークラウドへの負荷は大幅に軽減されました。
以前のリリースでは、director でデプロイされた swift は、Red Hat OpenStack Platform 8 から廃止された非推奨バージョンの ceilometer ミドルウェアを使用していました。今回の更新により、swift プロキシーの設定には python-ceilometermiddleware からの ceilometer ミドルウェアが使用されるようになり、swift プロキシーはサポートされているバージョンの ceilometer ミドルウェアを使用するようになりました。
デフォルトで設定される OpenStack Image Storage (glance) のワーカーの数が増え、パフォーマンスが向上しました。この数は、プロセッサーの数に応じて自動的にスケーリングされます。
今回の機能拡張により、Red Hat OpenStack Platform director で Open vSwitch (OVS) ファイアウォールドライバーを設定するための新しいパラメーター「NeutronOVSFirewallDriver」が追加されました。
このパラメーターは、neutron OVS エージェントがセキュリティーグループを実装するための新たなメカニズムである「openvswitch」ファイアウォールをサポートしているために追加されました。「NeutronOVSFirewallDriver」によりユーザーは使用する実装を直接制御することができます。
「hybrid」: neutron が以前の iptables/ハイブリッドベースの実装を使用するように設定します。
「openvswitch」: 新たなフローベースの実装を有効にします。 
新しい Open vSwitch (OVS) ファイアウォールドライバーにより、パフォーマンスが向上し、プロジェクトネットワークへの接続に使用するインターフェースとブリッジの数が削減されます。その結果、ユーザーは新たなセキュリティーグループの実装をより簡単に評価することができるようになりました。
Telemetry API (ceilometer-api) はイベントレットの代わりに apache-wsgi を使用するようになりました。本リリースにアップグレードする際には、ceilometer-api が適切に移行されます。

今回の変更によりデプロイメントごとのパフォーマンスとスケーリングの調整における柔軟性が向上し、SSL の使用が簡単になりました。
今回の更新により、オーバークラウドのデプロイ時に追加の環境ファイルを使用してオーバークラウド内の Object Storage サービス (swift) を無効にすることができます。この環境ファイルには、以下の内容を記載する必要があります。 

resource_registry:
  OS::TripleO::Services::SwiftProxy: OS::Heat::None
  OS::TripleO::Services::SwiftStorage: OS::Heat::None
  OS::TripleO::Services::SwiftRingBuilder: OS::Heat::None

その結果、Object Storage サービスはオーバークラウドで実行されなくなり、オーバークラウドの Identity サービス内の Object Storage サービスのエンドポイントはなくなります。
以前のリリースでは、director を使用した Red Hat OpenStack Platform 8 のデプロイ中に Compute で Telemetry サービスは設定されなかったため、OpenStack Integration Test Suite の一部のテストが失敗していました。 

今回の更新により、Compute の設定で OpenStack Telemetry サービスが設定されるようになったので、通知ドライバーは正しく設定され、OpenStack Integration Test Suite のテストが合格するようになりました。
以前のリリースでは、Telemetry (ceilometer) の通知は、Image サービス (glance) でメッセージングの設定がなかったことが原因で失敗していました。そのため、glance の通知の処理が失敗していました。今回の更新により、tripleo のテンプレートが変更されて、正しい設定が追加されたため、glance の通知は正しく処理されるようになりました。
今回の機能拡張により、RabbitMQ に Queue Master 分散の新たな HA 機能が導入されました。そのストラテジーの 1 つは「min-masters」で、最小数のマスターをホストするノードを選択します。
この機能は、コントローラーの 1 つが利用できなくなる可能性があり、その場合にはキューの宣言中に利用可能なコントローラーに Queue Master が配置されるために追加されました。利用不可だったコントローラーが再度利用可能になると、新たに宣言されたキューのマスターは、キューマスターの数が明らかに低いコントローラーを優先するようには配置されなかったため、分散が不均衡となって、複数のフェイルオーバーが発生した場合にコントローラーにかかる負荷が大幅に高くなる可能性がありました。
そのため、今回の機能拡張でコントローラーのフェイルオーバーの発生後には、キューがコントローラー全体に広げられるようになりました。
Red Hat OpenStack Platform director は OpenStack Block Storage (cinder) v3 API エンドポイントを OpenStack Identity (keystone) に作成して、より新しい Cinder API バージョンをサポートするようになりました。
今回の更新により、任意のロール上で任意の分離ネットワークを使用できるようになりました。「ceph-osd」が「nova-compute」とコロケーションされているデプロイメントなどの一部のシナリオは、ノードが複数の分離ネットワークにアクセス可能であることを前提としています。カスタムの NIC テンプレートにより、任意のロール上で任意の分離ネットワークを設定することができるようになりました。
Telemetry サービス (ceilometer) はデフォルトのメーターディスパッチャーバックエンドに Gnocchi を使用するようになりました。Gnocchi はよりスケーラブルで、Telemetry サービスの今後の方向性により整合しています。
今回の更新により、追加の環境ファイルを使用してオーバークラウドをデプロイすることによって、Object Storage サービス (swift) に追加の RAW ディスクを設定できるようになりました。以下に例を示します。

parameter_defaults:
  ExtraConfig:
    SwiftRawDisks:
      sdb:
        byte_size: 2048
        mnt_base_dir: /src/sdb
      sdc:
        byte_size: 2048

その結果、Object Storage サービスはローカルノードの「root」ファイルシステムのみに限定されなくなりました。
AODH は MYSQLをデフォルトのデータベースバックエンドとして使用するようになりました。以前のリリースでは、Ceilometer から AODH の移行を容易にする目的で、AODH は MongoDB をデフォルトのバックエンドとして使用していました。
以前は、Red Hat OpenStack Platform 9 (mitaka) から Red Hat OpenStack Platform 10 (newton) にアップグレードするための Compute ロールおよび Object Storage ロールのアップグレードスクリプトでエラーが発生して、想定どおりに終了しなかったため、アップグレードが失敗した場合でも、「upgrade-non-controller.sh」スクリプトはコード 0 (success) を返していました。 

今回の更新により、Compute ロールと Object Storage ロールのアップグレードスクリプトはアップグレードプロセス中にエラー終了してアップグレードが失敗した場合には、「upgrade-non-controller.sh」はゼロ以外 (失敗) の値を返すようになりました。
コンポーザブルサービスへの移行で、オーバークラウド上で NTP サーバーを設定するのに使用される Hiera データが誤って設定されていました。 

今回の更新では、正しい Hiera データを使用するようになり、オーバークラウドノードで NTP サーバーが設定されるようになりました。
コンポーザブルサービスに対応するために、Image サービス (glance) バックエンドとして使用する NFS マウントは Pacemaker によって管理されなくなったため、glance NFS バックエンドパラメーターのインターフェースが変更され、新しいメソッドでは環境ファイルを使用して NFS バックエンドを有効化するようになりました。以下に例を示します。
----
parameter_defaults:
GlanceBackend: file
GlanceNfsEnabled: true
GlanceNfsShare: IP:/some/exported/path
----
注記: GlanceNfsShare の設定はデプロイメントによって異なります。
また、「GlanceNfsOptions」パラメーターを使用してマウントオプションをカスタマイズすることができます。Glance NFS バックエンドを以前 Red Hat OpenStack Platform 9 で使用していた場合には、環境ファイルの内容を更新して、Red Hat OpenStack Platform 10 の書式と一致するようにする必要があります。
以前のリリースでは、TCP ポート「16509」が「iptables」でブロックされていました。そのため、コンピュートノード間での「nova」Compute 「libvirt」インスタンスのライブマイグレーションは実行できませんでした。 

今回の更新で、TCP ポート「16509」は「iptables」で開放されるように設定されたので、「nova」Compute「libvirt」インスタンスをコンピュートノード間でライブマイグレーションできるようになりました。
以前のリリースでは、ノード上での Hiera データの書き込みと Puppet の実行で競合状態が発生するために、Hiera データが不足して、オーバークラウドノード上で Puppet が失敗する場合がありました。

今回の更新により、プロセスが順番に実行されるようになり、まず最初に Hiera データの書き込みが全ノードで完了してから Puppet が実行されるようになりました。その結果、必要な Hiera データはすべて存在し、Puppet の実行中にエラーが発生しなくなりました。
以前は、Red Hat OpenStack Platform 9 (Mitaka) から Red Hat OpenStack Platform 10 (Newton) にアップグレードした後に「ceilometer-compute-agent」はデータ収集に失敗していました。

今回の更新により、「ceilometer-compute-agent」のアップグレード後のプロセスによって問題が修正され、「ceilometer-compute-agent」が正しく再起動して関連データを収集するようになりました。
以前のリリースでは、OpenStack Platform director は、OpenStack File Share API (manila-api) をデプロイする際にファイアウォールを更新しませんでした。manila-api サービスをコントローラーから独自のロールに移動した場合には、デフォルトのファイアウォールルールによりエンドポイントがブロックされていました。今回の修正により、オーバークラウドの Heat テンプレートコレクションで manila-api のファイアウォールルールが更新され、manila-api がコントローラーノードとは別のロールにある場合でもエンドポイントに到達できるようになりました。
以前のリリースでは、director は cloudformation (heat-cfn) エンドポイントを「regionOne」ではなく「RegionOne」に設定していました。このため、UI が異なるサービスで 2 つのリージョンを表示していました。今回の修正により、エンドポイントは「regionOne」を使用するように設定され、UI では全サービスが同じ 1 つのリージョンに表示されるようになりました。
今回の更新で、UI を使用してノードを追加できるようになりました。
今回の更新の以前は、「os-collect-config」に対する設定の HTTP 要求では、要求のタイムアウトが指定されていませんでした。そのため、アンダークラウドがアクセスできない間 (例: アンダークラウドのリブート、ネットワーク接続の問題など) には、「os-collect-config」が停止して、ポーリングや設定は一切実行されませんでした。多くの場合、この状態は、オーバークラウドスタックの操作が実行されてソフトウェアの設定がタイムアウトにならなければ判明しませんでした。
今回の更新により、「os-collect-config」HTTP 要求では常にタイムアウトが指定されるようになりました。
その結果、アンダークラウドが利用できない場合にはポーリングが失敗し、利用できるようになるとポーリングが再開するようになりました。
今回の更新の以前は、Open vSwitch と neutron 間の統合の改善が原因で、再起動後の接続の再開で問題が発生して、ノードに到達できなくなったり、接続性が低減したりする場合がありました。
今回の更新により、「os-net-config」はデフォルトで「fail_mode=standalone」を設定して、制御するエージェントが起動していない場合にネットワークトラフィックを許可するようになりました。その結果、再起動時の接続の問題は解決しました。
Ceph Storage ノードは、「ext4」でフォーマットされたローカルのファイルシステムを「ceph-osd」サービスのバックエンドとして使用していました。

注記: Red Hat OpenStack Platform 9 (Mitaka) の「overcloud-full」イメージの一部は「xfs」の代わりに「ext4」を使用して作成されていました。

Jewel リリースでは「ceph-osd」が、バックエンドで許可されているファイル名の最大長を確認して、Ceph 自体で設定されている上限よりも低い場合には拒否します。回避策として、Ceph Storage ノードにログインして以下のコマンドを実行すると、「ceph-osd」に使用中のファイルシステムを確認することができます。

# df -l --output=fstype /var/lib/ceph/osd/ceph-$ID

ここで $ID は OSD ID です。以下に例を示します。 

# df -l --output=fstype /var/lib/ceph/osd/ceph-0

注記: 単一の Ceph Storage ノードは、複数の「ceph-osd」インスタンスをホストしている可能性があり、その場合には、複数のサブディレクトリーが各インスタンスの「/var/lib/ceph/osd/」に存在することになります。

OSD インスタンスの*いずれか*が「ext4」ファイルシステムでバッキングされている場合には、Ceph が短いファイル名を使用するように設定する必要があります。これは、以下の内容を記載した追加の環境ファイルをデプロイ/アップグレードすることによって設定することができます。

parameter_defaults:
  ExtraConfig:
    ceph::profile::params::osd_max_object_name_len: 256
    ceph::profile::params::osd_max_object_namespace_len: 64

その結果、Red Hat OpenStack Platform 9 から Red Hat OpenStack Platform 10 へのアップグレード後に、各「ceph-osd」インスタンスが稼働しているかどうかを確認できるようになります。
「ceph-osd」インスタンスを SELinux ポリシーで制限できるようになりました。OSP 10 では、新規デプロイでは、Ceph Storage ノード上で SELinux が「enforcing」モードで設定されるようになりました。
以前のリリースでは、新規オーバークラウドで以前のクラスターの Ceph ノードを再利用すると、オーバークラウドのデプロイメントプロセス中に新しい Ceph クラスターでメッセージを表示せずにエラーが発生していました。これは、古い Ceph OSD ノードのディスクを再利用する前にクリーニングする必要があるためでした。今回の修正により、Ceph OpenStack Puppet モジュールにチェックが追加され、 OpenStack Platform のドキュメント [1] に記載されているとおりにディスクがクリーンな状態であることを確認するようになり、クリーンでない OSD ディスクが検出された場合には、オーバークラウドのデプロイメントプロセスが適切に失敗するようになりました。「openstack stack failures list overcloud」コマンドを実行すると、FSID が一致しないディスクが表示されます。 
[1] https://access.redhat.com/documentation/en/red-hat-openstack-platform/10/single/red-hat-ceph-storage-for-the-overcloud/#Formatting_Ceph_Storage_Nodes_Disks_to_GPT
以前のリリースでは、ループデバイスの設定と Block Storage ノード上に LVM 物理ボリュームが存在するかどうかの確認で競合状態が発生していました。このため、Puppet は既存の LVM 物理ボリュームの検出に失敗してそのボリュームの再作成を試みるためにメジャーアップグレードのコンバージェンスステップが失敗していました。今回の修正により、ループデバイスの設定後には udev イベントの完了を待つようになり、Puppet はループデバイスの設定が完了してから既存の LVM 物理デバイスがあるかどうかの確認を試みるようになりました。LVM バックエンドを使用する Block Storage ノードは、正常にアップグレードされるようになりました。
OpenStack Platform director は、OpenStack Orchestration (heat) の YAQL 表現を使用するためにデフォルトのメモリー上限を超えていました。このため、「Expression consumed too much memory」というエラーがオーバークラウドのデプロイメント中に表示され、その後にデプロイメントが失敗していました。今回の修正により、director のデフォルトのメモリー上限が増やされて、オーバークラウドのデプロイではエラーが発生しないようになりました。
ironic-inspector サーバーには、UEFI ブートローダーで機能する iPXE バージョンがありませんでした。UEFI ブートローダーを使用するマシンは、イントロスペクション ramdisk をチェーンロードできませんでした。今回の修正により、ipxe.efi ROM が  ironic-inspector サーバー上に存在するようになり、dnsmasq 設定を更新して、イントロスペクション中に UEFI ベースのマシンに送信するようになったので、director は BIOS および UEFI マシンの両方を検査することができます。
rabbitmqctl は、パラメーターが不足していたため、IPv6 環境で機能しませんでした。今回の修正により、RabbitMQ Puppet の設定が変更されて、不足していたパラメーターが /etc/rabbitmq/rabbitmq-env.conf に追加されたので、rabbitmqctl は IPv6 環境で正常に機能するようになりました。
今回の更新の以前は、エラーの発生したノードがサービスから削除される前に HAProxy が MySQL をチェックするため、タイムアウトが長くなり (16 秒)、エラーの発生した My SQL ノードに接続された OpenStack のサービスがユーザー/オペレーター/ツールに対して API エラーを返す場合がありました。
今回の更新により、このチェック間隔の設定が短くなり、エラーの発生した MySQL ノードは、そのエラーから 6 秒以内にドロップされるようになりました。OpenStack のサービスが稼働中の MySQL ノードにフェイルオーバーする速度がはるかに早くなり、コンシューマーに対して API エラーが表示されることは少なくなりました。
director を使用して Ceph RBD を Block Storage バックアップターゲットとして設定できるようになりました。これにより、ボリュームを Ceph ターゲットにバックアップするように設定してオーバークラウドをデプロイすることができます。デフォルトでは、ボリュームのバックアップは「backups」という名前の Ceph プールに保管されます。

バックアップの設定は、以下の環境ファイル (アンダークラウド上) で設定されます。

/usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml
以前のリリースでは、Pacemaker で Redis と RabbitMQ の両方の開始および停止のタイムアウトが 120s に設定されていました。一部の環境では、この設定は十分でなかったため、再起動が失敗していました。今回の修正により、タイムアウトは 200s に延長され、他の systemd リソースと同じになりました。大半の環境で Redis と RabbitMQ が再起動するための時間が十分となりました。
RBD バックエンドドライバー (Ceph Storage) を OpenStack Compute (nova) の一時ディスクにすると、以下の 2 つの追加設定を libvirt に適用します。

hw_disk_discard : unmap
disk_cachemodes : network=writeback

これにより、Ceph プール上の未使用ブロックを再利用し、ネットワークの書き込みをキャッシュすることができるので、RBD ドライバーを使用する OpenStack Compute 一時ディスクのパフォーマンスが向上します。

http://docs.ceph.com/docs/master/rbd/rbd-openstack/ も参照してください。
以前のリリースでは、旧バージョンの「cotyledon」のバグが原因で「metricsd」が適切に起動せずにトレースバックをスローしていました。
今回の更新にはより新しい 1.2.7-2 の「cotyledon」パッケージが含まれているので、トレースバックは発生せずに、「metricsd」は正しく起動するようになりました。
今回の機能拡張により「admin」ユーザーは管理コンソールを使用してインスタンスに割り当てられている Floating IP の一覧を確認できるようになりました。この一覧はデプロイメント内の全プロジェクトを対象とします。 
以前のリリースでは、この情報はコマンドラインでのみ取得可能でした。
今回の更新で複数のテーマ設定がサポートされるようになりました。これは、ユーザーがフロントエンドを使用してテーマを動的に変更できるようにするために追加されました。一部のユースケースには、明るいテーマと暗いテーマを切り替える機能や、アクセシビリティー上の理由から高コントラストを有効にする機能などが含まれます。
その結果、ユーザーは実行時にテーマを選択することができます。
今回の機能拡張により、ドメインスコープのトークンを Dashboard (horizon) のログインに使用することができるようになりました。
この機能は、ドメインスコープのトークンを必要とする、よりリッチなロールセットを使用する場合に keystone v3 の認証管理を完全にサポートするために追加されました。django_openstack_auth はこのタイプのセッション用トークンの取得と維持をサポートする必要があります。
その結果、horizon は Red Hat OpenStack Platform 9 以降のバージョンでドメインスコープのトークンをサポートしています。
今回の更新により、リソースタイプをサポートする OpenStack Telemetry Metrics (gnocchi) が提供されるようになりました。
OpenStack Bare Metal Provisioning サービス (ironic) は、追加のプライマリーパーティションとしてコンフィグドライブを作成して、新規ノードにユーザーデータを提供します。これには、ノードのディスク上に未使用のプライマリーパーティションが必要ですが、以前のリリースではバグが原因で OpenStack Bare Metal Provisioning サービスはプライマリーパーティションと拡張パーティションを区別できなかったため、パーティションカウントでは、コンフィグドライブに利用可能な空きパーティションがないものと報告されていました。今回の更新でプライマリーパーティションと拡張パーティションが区別されるようになり、デプロイメントはエラーが発生することなく正常に完了するようになりました。
OpenStack Bare Metal Provisioning サービス (ironic) では、ディスクイメージ全体に対するコンフィグドライブ実装で解析エラーがあったため、デプロイメントが失敗していました。今回の更新により、コンフィグドライブ実装で返される値の解析が正しく修正され、コンフィグドライブを使用してディスクイメージ全体をデプロイできるようになりました。
OpenStack Dashboard (horizon) は、OpenStack Identity (keystone) のエンドポイント作成に director が使用するサービスのリストに誤って含まれていました。オーバークラウドのデプロイ時には、誤解を招く恐れのある「Skipping "horizon" postconfig」というメッセージが表示されていました。今回の修正により、keystone に追加されるサービスリストエンドポイントから horizon が削除され、「skipping postconfig」のメッセージはデバッグモードのみで表示されるように変更されたので、紛らわしい「Skipping "horizon" postconfig」というメッセージは表示されなくなりました。
DHCP HA を使用する場合には、コンポーザブルロールを使用して、「NeutronDhcpAgentsPerNetwork」の値を dhcp-agent 数に等しい値または 3 のいずれか低い方に設定すべきです。このように設定しなかった場合には、この値はデフォルトで「ControllerCount」に設定され、各ネットワークで多数の DHCP サーバーの起動に対応するために dhcp-agent 数が十分でない場合があるために最適ではありません。
ノードの削除の関数は、Heat の「parameter_defaults」ではなく「parameters」を使用していたため、Heat が意図せずにノードを再デプロイしてしまうなど、一部のリソースが再デプロイされていました。今回の修正により、ノードの削除の関数には「parameter_defaults」のみが使用されるようになり、Heat のリソースは正しく保持されるようになり、再デプロイされなくなりました。
python-twisted パッケージは Red Hat OpenStack Platform 10 アンダークラウドインストールの一部としてのインストールで失敗していました。これは、パッケージの「Obsoletes」が存在しなかったことが原因でした。今回の修正により、パッケージが変更され「Obsoletes」一覧が追加されたので、python-twisted パッケージのインストール中に古いパッケージは削除され、更新とクリーンアップがシームレスに提供されるようになりました。

手動の回避策としては、Red Hat Enterprise Linux 7.3 Optional リポジトリーからは python-twisted-* パッケージ (例: python-twisted-core) は一切インストールしないようにします。アンダークラウドにこれらの古いパッケージが含まれている場合には、以下のコマンドで削除します。

$ yum erase python-twisted-*
RabbitMQ はポート 35672 にバインディングしていましたが、ポート 35672 は一時的なポートの範囲内にあるので、他のサービスが同じポートを開くことが可能でした。その場合には RabbitMQ は起動に失敗してしまう可能性がありました。今回の修正により、RabbitMQ のポートは一時的なポートの範囲外にある 25672 に変更されたので、他のサービスが同じポートをリッスンすることはなくなり、RabbitMQ は正常に起動するようになりました。
今回の更新には、OSP director を使用してデプロイされたオーバークラウドのバージョンを特定するためのリリースファイルが含まれるようになりました。この情報により、インストール済みのバージョンが明確にわかるので、デバッグに役立ちます。overcloud-full イメージには新規パッケージ (rhosp-release) が含まれています。旧バージョンからアップグレードする場合にもこの RPM がインストールされます。リリースファイルは、OSP 10 以降の全バージョンに含まれます。これは Red Hat OpenStack Platform director ベースのインストールにのみ適用されますが、ユーザーは rhosp-release パッケージを手動でインストールすると同じ結果を得ることができます。
今回の機能拡張により、「sahara-image-element」上のメインスクリプトが更新され、プラグインによってサポートされているイメージのみの作成ができるようになりました。たとえば、以下のコマンドを実行して、Red Hat Enterprise Linux 7 を使用する CDH 5.7 イメージを作成することができます。
----
>> ./diskimage-create/diskimage-create.sh -p cloudera -v 5.7

Usage: diskimage-create.sh
       [-p cloudera|mapr|ambari]
       [-v 5.5|5.7|2.3|2.4]
       [-r 5.1.0]
----
~~~
Code surrounded in tildes is easier to read
~~~

チャンネル	リポジトリー名
Red Hat Enterprise Linux 7 Server (RPMS)	`rhel-7-server-rpms`
Red Hat Enterprise Linux 7 Server - RH Common (RPMs)	`rhel-7-server-rh-common-rpms`
Red Hat Enterprise Linux High Availability (for RHEL 7 Server)	`rhel-ha-for-rhel-7-server-rpms`
Red Hat OpenStack Platform 10 for RHEL 7 (RPMs)	`rhel-7-server-openstack-10-rpms`
Red Hat Enterprise Linux 7 Server - Extras (RPMs)	`rhel-7-server-extras-rpms`

チャンネル	リポジトリー名
Red Hat Enterprise Linux 7 Server - Optional	`rhel-7-server-optional-rpms`
Red Hat OpenStack Platform 10 Operational Tools for RHEL 7 (RPMs)	`rhel-7-server-openstack-10-optools-rpms`

チャンネル	リポジトリー名
Red Hat CloudForms Management Engine	`"cf-me-*"`
Red Hat Enterprise Virtualization	`"rhel-7-server-rhev*"`
Red Hat Enterprise Linux 7 Server - Extended Update Support	`"*-eus-rpms"`

リリースノート

Red Hat OpenStack Platform 10 リリースの詳細

OpenStack Documentation Team

第1章 はじめに

1.1. 本リリースについて

1.2. 要件

1.3. デプロイメント制限事項

1.4. データベースサイズの管理

1.5. 認定済みのドライバーとプラグイン

1.6. 認定済みゲストオペレーティングシステム

1.7. Bare Metal Provisioning でサポートされているオペレーティングシステム

1.8. ハイパーバイザーのサポート

1.9. コンテンツ配信ネットワーク (CDN) チャンネル

1.10. 製品サポート

第2章 最も重要な新機能

2.1. Red Hat OpenStack Platform Director

2.2. Compute

2.3. Dashboard

2.4. Identity

2.5. Object Storage

2.6. OpenStack Networking

2.7. Shared File System

2.8. 高可用性

2.9. Bare Metal Provisioning サービス

2.10. OpenStack Integration Test Suite サービス

2.11. OpenStack Data Processing サービス

2.12. テクノロジープレビュー

2.12.1. 新規テクノロジープレビュー

2.12.2. 以前にリリースされたテクノロジープレビュー

第3章 リリースの情報

3.1. 機能拡張

3.2. テクノロジープレビュー

3.3. リリースノート

3.4. 既知の問題

3.5. 非推奨の機能

第4章 テクニカルノート

4.1. RHEA-2016:2948 — Red Hat OpenStack Platform 10 の機能拡張についての最新情報

法律上の通知

第1章はじめに

第2章最も重要な新機能

第3章リリースの情報

第4章テクニカルノート