手順

1. OSPdO プロジェクトを作成します。

   $ oc new-project openstack

2. https://catalog.redhat.com/software/containers/search から最新の osp-director-operator-bundle イメージを取得します。
3. Operator Package Manager (opm) ツールを https://console.redhat.com/openshift/downloads からダウンロードします。

4. opm ツールを使用してインデックスイメージを作成します。

   $ BUNDLE_IMG="registry.redhat.io/rhosp-rhel9/osp-director-operator-bundle:1.3.1"
   $ INDEX_IMG="quay.io/<account>/osp-director-operator-index:x.y.z-a"
   $ opm index add --bundles ${BUNDLE_IMG} --tag ${INDEX_IMG} -u podman --pull-tool podman

5. インデックスイメージをレジストリーにプッシュします。

   $ podman push ${INDEX_IMG}

6. OSPdO のインストールに必要な CatalogSource、OperatorGroup、および Subscription CR を設定する環境ファイル (例: osp-director-operator.yaml) を作成します。

7. CatalogSource CR を設定するには、次の設定を osp-director-operator.yaml に追加します。

   apiVersion: operators.coreos.com/v1alpha1
   kind: CatalogSource
   metadata:
     name: osp-director-operator-index
     namespace: openstack
   spec:
     sourceType: grpc
     image: quay.io/<account>/osp-director-operator-index:x.y.z-a

   Operator デプロイメントがイメージをプルできるように Quay 認証を適用する方法は、プライベートレジストリーから Operator のイメージにアクセスする を参照してください。

8. OperatorGroup CR を設定するには、次の設定を osp-director-operator.yaml に追加します。

   ---
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: "osp-director-operator-group"
     namespace: openstack
   spec:
     targetNamespaces:
     - openstack

9. サブスクリプション CR を設定するには、次の設定を osp-director-operator.yaml に追加します。

   ---
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: osp-director-operator-subscription
     namespace: openstack
   spec:
     config:
       env:
       - name: WATCH_NAMESPACE
         value: openstack,openshift-machine-api,openshift-sriov-network-operator
     source: osp-director-operator-index
     sourceNamespace: openstack
     name: osp-director-operator

10. openstack namespace 内に新規の CatalogSource、Subscription、および Subscription CR を作成します。

    $ oc apply -f osp-director-operator.yaml

11. インストールされているオペレーターをリストして、OSPdO、osp-director-operator.openstack がインストールされていることを確認します。

    $ oc get operators
    NAME                                     AGE
    osp-director-operator.openstack          5m

手順

1. Red Hat Customer Portal の 製品ダウンロード セクションから RHEL 9.2 QCOW2 イメージをワークステーションにダウンロードします。

2. オプション: カスタム CA 証明書を追加します。

   $ sudo -s
   $ export LIBGUESTFS_BACKEND=direct
   $ virt-copy-in -a <local_path_to_image> <ca_certificate>.pem /etc/pki/ca-trust/source/anchors/

   Identity Service の LDAP 通信を保護したり、RHOSP 以外のシステムと通信したりするために、カスタム CA 証明書を追加することができます。

3. イメージをカスタマイズして、予測可能なネットワークインターフェイス名を割り当てるスクリプトを作成します。

   #!/bin/bash
   set -eux
   
   if [ -e /etc/kernel/cmdline ]; then
     echo 'Updating /etc/kernel/cmdline'
     sed -i -e "s/^\(.*\)net\.ifnames=0\s*\(.*\)/\1\2/" /etc/kernel/cmdline
   fi
   
   source /etc/default/grub
   if grep -q "net.ifnames=0" <<< "$GRUB_CMDLINE_LINUX"; then
     echo 'Updating /etc/default/grub'
     sed -i -e "s/^\(GRUB_CMDLINE_LINUX=.*\)net\.ifnames=0\s*\(.*\)/\1\2/" /etc/default/grub
   fi
   if [ "$GRUB_ENABLE_BLSCFG" == "true" ]; then
     echo 'Fixing BLS entries'
     find /boot/loader/entries -type f -exec sed -i -e "s/^\(.*\)net\.ifnames=0\s*\(.*\)/\1\2/" {} \;
   fi
   # Always do this, on RHEL8 with BLS we still need it as the BLS entry uses $kernelopts from grubenv
   echo 'Running grub2-mkconfig'
   grub2-mkconfig -o /etc/grub2.cfg
   grub2-mkconfig -o /etc/grub2-efi.cfg
   rm -f /etc/sysconfig/network-scripts/ifcfg-ens* /etc/sysconfig/network-scripts/ifcfg-eth*
   update-ca-trust extract

4. イメージのカスタマイズスクリプトを実行します。

   $ sudo -s
   $ export LIBGUESTFS_BACKEND=direct
   $ chmod 755 customize_image.sh
   $ virt-customize -a <local_path_to_image> --run customize_image.sh --truncate /etc/machine-id

5. virtctl を使用してイメージを OpenShift Virtualization にアップロードします。

   $ virtctl image-upload dv <datavolume_name> -n openstack \
    --size=<size> --image-path=<local_path_to_image> \
    --storage-class <storage_class> --access-mode <access_mode> --insecure

   • <datavolume_name> をデータボリュームの名前 (例: openstack-base-img) に置き換えます。
   • <size> を、環境に必要なデータボリュームのサイズ (たとえば、50Gi) に置き換えます。最小サイズは 50GB です。

   • <storage_class> をクラスターの必要なストレージクラスに置き換えます。次のコマンドを使用して、利用可能なストレージクラスを取得します。

     $ oc get storageclass

   • <access_mode> を、PVC のアクセスモードに置き換えます。デフォルト値は ReadWriteOnce です。

手順

1. git-secret シークレットリソースを作成します。

   $ oc create secret generic <secret_name> -n <namespace> \
    --from-file=git_ssh_identity=<path_to_private_SSH_key> \
    --from-literal=git_url=<git_server_URL>

   • <secret_name> をシークレットの名前 (この場合は git-secret に置き換えます。
   • <namespace> を openstack などにシークレットを作成するネームスペースの名前に置き換えます。
   • <path_to_private_SSH_key> を Git リポジトリーにアクセスするための秘密鍵へのパスに置き換えます。
   • <git_server_URL> を、OSPdO 設定を保存する git リポジトリーの SSH URL (ssh://<user>@<server>:2202/repo.git など) に置き換えます。

2. Secret リソースが作成されたことを確認します。

   $ oc get secret/git-secret -n openstack

手順

1. 選択したパスワードを base64 値に変換します。

   $ echo -n "p@ssw0rd!" | base64
   cEBzc3cwcmQh

   重要

   -n オプションは、echo 出力から末尾の改行を削除します。

2. ワークステーションに openstack-userpassword.yaml という名前のファイルを作成します。ファイルに、Secret の以下のリソース仕様を追加します。

   apiVersion: v1
   kind: Secret
   metadata:
     name: <secret_name>
     namespace: openstack
   data:
     NodeRootPassword: "<password>"

   • <secret_name> をこのシークレットリソースの名前 (userpassword など) に置き換えます。
   • <password> を、base64 でエンコードされたパスワードに置き換えます。

3. userpassword シークレットを作成します。

   $ oc create -f openstack-userpassword.yaml -n openstack

手順

1. ワークステーション上に openstacknetconfig.yaml という名前のファイルを作成します。

2. 次の設定を openstacknetconfig.yaml に追加して、OpenStackNetConfig カスタムリソース (CR) を作成します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackNetConfig
   metadata:
     name: openstacknetconfig

3. ネットワークに必要なブリッジのネットワークアタッチメント定義を設定します。たとえば、次の設定を openstacknetconfig.yaml に追加して RHOSP ブリッジのネットワーク接続定義 br-osp を作成し、nodeNetworkConfigurationPolicy オプションを設定して Linux ブリッジを作成します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackNetConfig
   metadata:
     name: openstacknetconfig
   spec:
     attachConfigurations:
       br-osp: 1
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp6s0 2
               description: Linux bridge with enp6s0 as a port
               name: br-osp 3
               state: up
               type: linux-bridge
               mtu: 1500 4
     # optional DnsServers list
     dnsServers:
     - 192.168.25.1
     # optional DnsSearchDomains list
     dnsSearchDomains:
     - osptest.test.metalkube.org
     - some.other.domain
     # DomainName of the OSP environment
     domainName: osptest.test.metalkube.org

   1

   br-osp のネットワーク接続定義。

   2

   各ホストに接続する NIC/イーサネットデバイス。

   3

   インターフェイスの名前。

   4

   1 つのネットワークパケットで転送できるデータの最大量。

4. オプション: ブリッジにジャンボフレームを使用するには、ジャンボフレームを使用するようにブリッジインターフェイスを設定し、ブリッジの mtu の値を更新します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackNetConfig
   metadata:
     name: openstacknetconfig
   spec:
     attachConfigurations:
       br-osp:
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp6s0
               description: Linux bridge with enp6s0 as a port
               name: br-osp
               state: up
               type: linux-bridge
               mtu: 9000 1
             - name: enp6s0 2
               description: Configuring enp6s0 on workers
               type: ethernet
               state: up
               mtu: 9000
     ...

   1

   ジャンボフレームを使用して、1 つのネットワークパケットで転送できるデータの最大量を更新します。

   2

   ジャンボフレームを使用するようにブリッジインターフェイスを設定します。

5. 各オーバークラウドネットワークを定義します。次の例では、InternalAPI トラフィック用にコントロールプレーンネットワークと分離されたネットワークを作成します。

   spec:
     ...
     networks:
     - name: Control 1
       nameLower: ctlplane 2
       subnets: 3
       - name: ctlplane 4
         ipv4: 5
           allocationEnd: 172.22.0.250
           allocationStart: 172.22.0.100
           cidr: 172.22.0.0/24
           gateway: 172.22.0.1
         attachConfiguration: br-osp 6
     - name: InternalApi 7
       nameLower: internal_api
       mtu: 1350
       subnets:
       - name: internal_api
         attachConfiguration: br-osp
         vlan: 20 8
         ipv4:
           allocationEnd: 172.17.0.250
           allocationStart: 172.17.0.10
           cidr: 172.17.0.0/24
     ...

   1

   ネットワークの名前 (例: Control)。

   2

   ネットワーク名の小文字バージョン (ctlplane など)。

   3

   サブネットの仕様。

   4

   サブネットの名前 (ctlplane など)。

   5

   allocationStart、allocationEnd、cidr、gateway、オプションのルートリスト (destination と nexthop を含む) を含む ipv4 サブネットの詳細

   6

   ネットワークを接続するネットワーク接続定義。この例では、RHOSP ブリッジ br-osp が各ワーカーの NIC に接続されています。

   7

   コンポーザブルネットワークのネットワーク定義。デフォルトの RHOSP ネットワークを使用するには、ネットワークごとに OpenStackNetConfig リソースを作成する必要があります。デフォルトの RHOSP ネットワークは、デフォルトの Red Hat OpenStack Platform ネットワーク を参照してください。異なるネットワークを使用するには、カスタム network_data.yaml ファイルを作成する必要があります。カスタムの network_data.yaml ファイルの作成は、オーバークラウドネットワークの設定 を参照してください。

   8

   ネットワーク VLAN。デフォルトの RHOSP ネットワークは、デフォルトの Red Hat OpenStack Platform ネットワーク を参照してください。OpenStackNetConfig CRD を使用した仮想マシンブリッジングの詳細は、OpenStackNetConfig CRD を使用した仮想マシンブリッジングについて を参照してください。

6. オプション: 特定のノード上のネットワーク用に静的 IP アドレスを予約します。

   spec:
     ...
     reservations:
       controller-0:
         ipReservations:
           ctlplane: 172.22.0.120
       compute-0:
         ipReservations:
           ctlplane: 172.22.0.140
           internal_api: 172.17.0.40
           storage: 172.18.0.40
           tenant: 172.20.0.40

   注記

   予約は、自動生成された IP アドレスよりも優先されます。

7. openstacknetconfig.yaml 定義ファイルを保存します。

8. オーバークラウドネットワークを作成します。

   $ oc create -f osnetconfig.yaml -n openstack

9. オーバークラウドネットワークが作成されたことを確認するには、オーバークラウドネットワークのリソースを表示します。

   $ oc get openstacknetconfig/openstacknetconfig

10. OpenStackNetConfig API と子リソースを表示します。

    $ oc get openstacknetconfig/openstacknetconfig -n openstack
    $ oc get openstacknetattachment -n openstack
    $ oc get openstacknet -n openstack

    エラーが表示された場合は、基礎となる network-attach-definition とノードのネットワーク設定ポリシーを確認してください。

    $ oc get network-attachment-definitions -n openstack
    $ oc get nncp

手順

1. カスタムテンプレートの場所に移動します。

   $ cd ~/custom_templates

2. テンプレートを gzip 圧縮された tarball にアーカイブします。

   $ tar -cvzf custom-config.tar.gz *.yaml

3. tripleo-tarball-config CR を作成し、tarball をデータとして使用します。

   $ oc create configmap tripleo-tarball-config --from-file=custom-config.tar.gz -n openstack

4. ConfigMap CR が作成されたことを確認します。

   $ oc get configmap/tripleo-tarball-config -n openstack

手順

1. heat-env-config ConfigMap オブジェクトを作成します。

   $ oc create configmap -n openstack heat-env-config \
    --from-file=~/<dir_custom_environment_files>/ \
    --dry-run=client -o yaml | oc apply -f -

   • <dir_custom_environment_files> をオーバークラウドのデプロイメントで使用する環境ファイルが含まれるディレクトリーに置き換えます。ConfigMap オブジェクトは、これらを個別の data エントリーとして保存します。

2. heat-env-config ConfigMap オブジェクトに必要な環境ファイルがすべて含まれていることを確認します。

   $ oc get configmap/<configmap_name> -n openstack

手順

1. ワークステーションに openstack-controller.yaml という名前のファイルを作成します。コントローラーノードのリソース仕様を含めます。次の例では、3 つのコントローラーノードで設定されるコントロールプレーンの仕様を定義します。

   apiVersion: osp-director.openstack.org/v1beta2
   kind: OpenStackControlPlane
   metadata:
     name: overcloud 1
     namespace: openstack 2
   spec: 3
     openStackClientNetworks:
           - ctlplane
           - internal_api
           - external
     openStackClientStorageClass: host-nfs-storageclass
     passwordSecret: userpassword 4
     virtualMachineRoles:
       Controller:
         roleName: Controller
         roleCount: 3
         networks:
           - ctlplane
           - internal_api
           - external
           - tenant
           - storage
           - storage_mgmt
         cores: 12
         memory: 64
         rootDisk:
           diskSize: 100
           baseImageVolumeName: openstack-base-img 5
           storageClass: host-nfs-storageclass 6
           storageAccessMode:  ReadWriteMany
           storageVolumeMode: Filesystem
         # optional configure additional discs to be attached to the VMs,
         # need to be configured manually inside the VMs where to be used.
         additionalDisks:
           - name: datadisk
             diskSize: 500
             storageClass: host-nfs-storageclass
             storageAccessMode:  ReadWriteMany
             storageVolumeMode: Filesystem
     openStackRelease: "17.1"

   1

   オーバークラウドのコントロールプレーンの名前 (例: overcloud)。

   2

   OSPdO 名前空間 (例: openstack)。

   3

   コントロールプレーンの設定。

   4

   オプション: パスワードを使用してユーザーに各ノードでの root アクセスを提供する Secret リソース。

   5

   Controller VM の基本オペレーティングシステムイメージを保存するデータボリュームの名前。データボリュームの作成の詳細は、ベースオペレーティングシステムのデータボリュームの作成 を参照してください。

   6

   Red Hat OpenShift Container Platform (RHOCP)ストレージの設定は、動的プロビジョニング を参照してください。

2. openstack-controller.yaml ファイルを保存します。

3. コントロールプレーンを作成します。

   $ oc create -f openstack-controller.yaml -n openstack

4. RHOCP が OpenStackControlPlane CR に関連するリソースを作成するまで待ちます。OSPdO は、リモートシェルを通じてアクセスして RHOSP コマンドを実行できる OpenStackClient Pod も作成します。

検証

1. コントロールプレーンのリソースを表示します。

   $ oc get openstackcontrolplane/overcloud -n openstack

2. OpenStackVMSet リソースを表示して、コントロールプレーンの仮想マシンセットの作成を確認します。

   $ oc get openstackvmsets -n openstack

3. VM を表示して、コントロールプレーン OpenShift Virtualization VM の作成を確認します。

   $ oc get virtualmachines

4. openstackclient リモートシェルにアクセスできるかをテストします。

   $ oc rsh -n openstack openstackclient

手順

1. ワークステーションに openstack-compute.yaml という名前のファイルを作成します。Compute ノードのリソース仕様を含めます。次の例では、1 つの Compute ノードの仕様を定義します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackBaremetalSet
   metadata:
     name: compute 1
     namespace: openstack 2
   spec: 3
     count: 1
     baseImageUrl: http://<source_host>/rhel-9.2-x86_64-kvm.qcow2
     deploymentSSHSecret: osp-controlplane-ssh-keys
     # If you manually created an OpenStackProvisionServer, you can use it here,
     # otherwise director Operator will create one for you (with `baseImageUrl` as the image that it server)
     # to use with this OpenStackBaremetalSet
     # provisionServerName: openstack-provision-server
     ctlplaneInterface: enp2s0
     networks:
       - ctlplane
       - internal_api
       - tenant
       - storage
     roleName: Compute
     passwordSecret: userpassword 4

   1

   Compute ノードのベアメタルセットの名前 (例: compute)。

   2

   OSPdO 名前空間 (例: openstack)。

   3

   Compute ノードの設定。

   4

   オプション: パスワードを使用してユーザーに各ノードでの root アクセスを提供する Secret リソース。

2. openstack-compute.yaml ファイルを保存します。

3. Compute ノードを作成します。

   $ oc create -f openstack-compute.yaml -n openstack

検証

1. Compute ノードのリソースを表示します。

   $ oc get openstackbaremetalset/compute -n openstack

2. RHOCP が管理するベアメタルマシンを表示し、Compute ノードの作成を確認します。

   $ oc get baremetalhosts -n openshift-machine-api

手順

1. ワークステーションに openstack-provision.yaml という名前のファイルを作成します。プロビジョニングサーバーのリソース仕様を含めます。次の例では、特定の RHEL 9.2 QCOW2 イメージを使用してプロビジョニングサーバーの仕様を定義します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackProvisionServer
   metadata:
     name: openstack-provision-server 1
     namespace: openstack 2
   spec:
     baseImageUrl: http://<source_host>/rhel-9.2-x86_64-kvm.qcow2 3
     port: 8080 4

   1

   OpenStackProvisionServer CR を識別する名前。

   2

   OSPdO 名前空間 (例: openstack)。

   3

   Provisioing サーバーの RHEL QCOW2 イメージの初期ソースを設定します。イメージは、サーバーの作成時にこのリモートソースからダウンロードされます。

   4

   プロビジョニングサーバーポート。デフォルトでは 8080 に設定されます。特定のポート設定に合わせて変更できます。

   OpenStackProvisionServer CR の設定に使用できる値の説明は、OpenStackProvisionServer CRD 仕様スキーマを参照してください。

   $ oc describe crd openstackprovisionserver

2. openstack-provision.yaml ファイルを保存します。

3. Provisioning サーバーを作成します。

   $ oc create -f openstack-provision.yaml -n openstack

4. プロビジョニングサーバーのリソースが作成されたことを確認します。

   $ oc get openstackprovisionserver/openstack-provision-server -n openstack

手順

1. ワークステーションに openstack-config-generator.yaml という名前のファイルを作成します。リソース仕様を追加して Ansible Playbook を生成します。次の例では、Playbook を生成するための仕様を定義します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackConfigGenerator
   metadata:
     name: default 1
     namespace: openstack
   spec:
     enableFencing: true 2
     gitSecret: git-secret 3
     imageURL: registry.redhat.io/rhosp-rhel8/openstack-tripleoclient:17.1
     heatEnvConfigMap: heat-env-config 4
     # List of heat environment files to include from tripleo-heat-templates/environments
     heatEnvs: 5
     - ssl/tls-endpoints-public-dns.yaml
     - ssl/enable-tls.yaml
     tarballConfigMap: tripleo-tarball-config 6

   1

   設定ジェネレータの名前。デフォルトではこれが default です。

   2

   true に設定すると、フェンシングを有効にするために必要な熱環境ファイルの自動作成が有効になります。本番 RHOSP 環境では、フェンシングを有効にする必要があります。pacemaker を実行する仮想マシンには、fence-agents-kubevirt パッケージが必要です。

   3

   Git 認証認証情報 (デフォルトでは git-secret) を含む ConfigMap オブジェクトに設定します。

   4

   カスタム環境ファイルを含む ConfigMap オブジェクト (デフォルトでは heat-env-config)。

   5

   Playbook の生成に使用する、TripleO によって TripleO-heat-templates/environments ディレクトリーに提供される、デフォルトの Heat 環境ファイルのリスト。

   6

   カスタム Heat テンプレートを含む tarball を含む ConfigMap オブジェクト (デフォルトでは Tripleo-tarball-config)。

2. オプション: OpenStackConfigGenerator CR が一時的 Heat サービスの作成に使用するコンテナーイメージの場所を変更するには、openstack-config-generator.yaml ファイルに次の設定を追加します。

   spec:
     ...​
     ephemeralHeatSettings:
       heatAPIImageURL: <heat_api_image_location>
       heatEngineImageURL: <heat_engine_image_location>
       mariadbImageURL: <mariadb_image_location>
       rabbitImageURL: <rabbitmq_image_location>

   • <heat_api_image_location> を、heat API イメージをホストするディレクトリー openstack-heat-api へのパスに置き換えます。
   • <heat_engine_image_location> を、ヒートエンジンイメージをホストするディレクトリーへのパス、openstack-heat-engine に置き換えます。
   • <mariadb_image_location> を、MariaDB イメージをホストするディレクトリー (openstack-mariadb) へのパスに置き換えます。
   • <rabbitmq_image_location> を、RabbitMQ イメージをホストするディレクトリー openstack-rabbitmq へのパスに置き換えます。

3. オプション: デバッグモードで設定を生成するための Ansible Playbook を作成するには、次の設定を openstack-config-generator.yaml ファイルに追加します。

   spec:
     ...​
     interactive: true

   対話モードでの OpenStackConfigGenerator Pod のデバッグの詳細は、設定生成のデバッグ を参照してください。

4. openstack-config-generator.yaml ファイルを保存します。

5. Ansible 設定ジェネレーターを作成します。

   $ oc create -f openstack-config-generator.yaml -n openstack

6. 設定ジェネレーターのリソースが作成されたことを確認します。

   $ oc get openstackconfiggenerator/default -n openstack

手順

1. OpenStackClient Pod への RSH 接続を開きます。

   $ oc rsh -n openstack openstackclient

2. cloud-admin ホームディレクトリーに移動します。

   $ cd /home/cloud-admin

3. ノードを登録する redhat_subscription モジュールを使用して Playbook を作成します。たとえば、以下の Playbook はコントローラーノードを登録します。

   ---
   - name: Register Controller nodes
     hosts: Controller
     become: yes
     vars:
       repos:
         - rhel-9-for-x86_64-baseos-eus-rpms
         - rhel-9-for-x86_64-appstream-eus-rpms
         - rhel-9-for-x86_64-highavailability-eus-rpms
         - openstack-17.1-for-rhel-9-x86_64-rpms
         - fast-datapath-for-rhel-9-x86_64-rpms
         - rhceph-6-tools-for-rhel-9-x86_64-rpms
     tasks:
       - name: Register system 1
         redhat_subscription:
           username: myusername
           password: p@55w0rd!
           org_id: 1234567
           release: 9.2
           pool_ids: 1a85f9223e3d5e43013e3d6e8ff506fd
       - name: Disable all repos 2
         command: "subscription-manager repos --disable *"
       - name: Enable Controller node repos 3
         command: "subscription-manager repos --enable {{ item }}"
         with_items: "{{ repos }}"

   1

   ノードを登録するタスク。

   2

   自動有効化されたリポジトリーを無効にするタスク。

   3

   コントローラーノードに関連するリポジトリーのみを有効にするタスク。リポジトリーは repos 変数でリストされます。

4. 必要なリポジトリーにオーバークラウドノードを登録します。

   $ ansible-playbook -i /home/cloud-admin/ctlplane-ansible-inventory ./rhsm.yaml

手順

1. 最新の OpenStackConfigVersion オブジェクトの hash/digest を取得します。これは、オーバークラウドの設定に使用する必要がある Ansible Playbook を表します。

   $ oc get -n openstack --sort-by {.metadata.creationTimestamp} openstackconfigversion -o json

2. ワークステーション上に openstack-deployment.yaml という名前のファイルを作成し、リソース仕様を Ansible Playbook に含めます。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: default
   spec:
     configVersion: <config_version>
     configGenerator: default

   • <config_version> を、ステップ 1 で取得した Ansible Playbook の hash/digest (例: n5fch96h548h75hf4hbdhb8hfdh676h57bh96h5c5h59hf4h88h...) に置き換えます。
3. openstack-deployment.yaml ファイルを保存します。

4. OpenStackDeploy リソースを作成します。

   $ oc create -f openstack-deployment.yaml -n openstack

   デプロイメントが実行すると、Ansible Playbook を実行するための Kubernetes ジョブが作成されます。ジョブのログを表示して、Ansible Playbook の実行を確認できます。

   $ oc logs -f jobs/deploy-openstack-default

   openstackclient Pod にログインすることで、実行された Ansible Playbook に手動でアクセスすることもできます。現在のデプロイメントの ansible Playbook と ansible.log ファイルは /home/cloud-admin/work/directory にあります。

手順

1. OpenStackConfigGenerator Pod へのリモートシェル (RSH) 接続を開きます。

   $ oc rsh $(oc get pod -o name -l job-name=generate-config-default)

2. ファイルと Playbook のレンダリングを検査します。

   $ ls -la /home/cloud-admin/
   ...
   config 1
   config-custom 2
   config-passwords 3
   create-playbooks.sh 4
   process-heat-environment.py 5
   tht-tars 6

手順

1. openstackclient のリモートシェルにアクセスします。

   $ oc rsh -n openstack openstackclient

2. OS_CLOUD 環境変数の設定を解除します。

   $ unset OS_CLOUD

3. cloud-admin ディレクトリーに移動します。

   $ cd /home/cloud-admin/

4. Controller ロールおよび ComputeHCI ロールを設定して、新しい roles_data.yaml ファイルを生成します。

   $ openstack overcloud roles generate -o roles_data.yaml Controller ComputeHCI

5. openstackclient Pod を終了します。

   $ exit

6. カスタムの roles_data.yaml ファイルを openstackclient Pod からカスタムテンプレートディレクトリーにコピーします。

   $ oc cp openstackclient:/home/cloud-admin/roles_data.yaml custom_templates/roles_data.yaml -n openstack

手順

1. カスタムテンプレートのディレクトリーを作成します。

   $ mkdir custom_templates

2. custom_templates ディレクトリーに multiple_nics_vlans_dvr.j2 という名前のカスタムテンプレートファイルを作成します。
3. ベアメタルノードの NIC の設定を multiple_nics_vlans_dvr.j2 ファイルに追加します。NIC 設定ファイルの例は、HCI Compute ノード用のカスタム NIC heat テンプレート を参照してください。

4. カスタム環境ファイルのディレクトリーを作成します。

   $ mkdir custom_environment_files

5. オーバークラウドロールの NIC テンプレートを、custom_environment_files ディレクトリーの network-environment.yaml 環境ファイルにマップします。

   parameter_defaults:
     ComputeHCINetworkConfigTemplate: 'multiple_nics_vlans_dvr.j2'

手順

1. カスタムテンプレートの場所に移動します。

   $ cd ~/custom_templates

2. テンプレートを gzip 圧縮された tarball にアーカイブします。

   $ tar -cvzf custom-config.tar.gz *.yaml

3. tripleo-tarball-config CR を作成し、tarball をデータとして使用します。

   $ oc create configmap tripleo-tarball-config --from-file=custom-config.tar.gz -n openstack

4. ConfigMap CR が作成されたことを確認します。

   $ oc get configmap/tripleo-tarball-config -n openstack

手順

1. heat-env-config ConfigMap オブジェクトを作成します。

   $ oc create configmap -n openstack heat-env-config \
    --from-file=~/<dir_custom_environment_files>/ \
    --dry-run=client -o yaml | oc apply -f -

   • <dir_custom_environment_files> をオーバークラウドのデプロイメントで使用する環境ファイルが含まれるディレクトリーに置き換えます。ConfigMap オブジェクトは、これらを個別の data エントリーとして保存します。

2. heat-env-config ConfigMap オブジェクトに必要な環境ファイルがすべて含まれていることを確認します。

   $ oc get configmap/<configmap_name> -n openstack

手順

1. ワークステーションに openstack-hcicompute.yaml という名前のファイルを作成します。HCI Compute のリソース仕様を含めます。たとえば、3 つの HCI Compute ノードの仕様は次のとおりです。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackBaremetalSet
   metadata:
     name: computehci 1
     namespace: openstack 2
   spec: 3
     count: 3
     baseImageUrl: http://<source_host>/rhel-9.2-x86_64-kvm.qcow2
     deploymentSSHSecret: osp-controlplane-ssh-keys
     ctlplaneInterface: enp8s0
     networks:
       - ctlplane
       - internal_api
       - tenant
       - storage
       - storage_mgmt
     roleName: ComputeHCI
     passwordSecret: userpassword 4

   1

   HCI Compute ノードのベアメタルセットの名前 (例: computehci)。

   2

   OSPdO 名前空間 (例: openstack)。

   3

   HCI Compute ノードの設定。

   4

   オプション: パスワードを使用してユーザーに各ノードでの root アクセスを提供する Secret リソース。

2. openstack-hcicompute.yaml ファイルを保存します。

3. HCI Compute ノードを作成します。

   $ oc create -f openstack-hcicompute.yaml -n openstack

4. HCI Compute ノードのリソースが作成されたことを確認します。

   $ oc get openstackbaremetalset/computehci -n openstack

5. HCI Compute ノードの作成を確認するには、RHOCP が管理するベアメタルマシンを表示します。

   $ oc get baremetalhosts -n openshift-machine-api

6. OpenStackConfigGenerator CRD を使用して、オーバークラウド設定用の Ansible Playbook を作成します。詳細は、OpenStackConfigGenerator CRD を使用したオーバークラウド設定用の Ansible Playbook の作成 を参照してください。
7. オーバークラウドのオペレーティングシステムを登録します。詳細は、オーバークラウドのオペレーティングシステムの登録 を参照してください。
8. オーバークラウド設定を適用します。詳細は、director Operator を使用したオーバークラウド設定の適用 を参照してください。

手順

1. カスタムテンプレートのディレクトリーを作成します。

   $ mkdir custom_templates

2. custom_templates ディレクトリーに multiple_nics_vlans_dvr.j2 という名前のカスタムテンプレートファイルを作成します。
3. ベアメタル Compute ノードの NIC の設定を multiple_nics_vlans_dvr.j2 ファイルに追加します。NIC 設定ファイルの例は、Compute ノード用のカスタム NIC heat テンプレート を参照してください。

4. カスタム環境ファイルのディレクトリーを作成します。

   $ mkdir custom_environment_files

5. オーバークラウドロールの NIC テンプレートを、custom_environment_files ディレクトリーの network-environment.yaml 環境ファイルにマップします。

   parameter_defaults:
     ComputeNetworkConfigTemplate: 'multiple_nics_vlans_dvr.j2'

手順

1. カスタムテンプレートの場所に移動します。

   $ cd ~/custom_templates

2. テンプレートを gzip 圧縮された tarball にアーカイブします。

   $ tar -cvzf custom-config.tar.gz *.yaml

3. tripleo-tarball-config CR を作成し、tarball をデータとして使用します。

   $ oc create configmap tripleo-tarball-config --from-file=custom-config.tar.gz -n openstack

4. ConfigMap CR が作成されたことを確認します。

   $ oc get configmap/tripleo-tarball-config -n openstack

手順

1. heat-env-config ConfigMap オブジェクトを作成します。

   $ oc create configmap -n openstack heat-env-config \
    --from-file=~/<dir_custom_environment_files>/ \
    --dry-run=client -o yaml | oc apply -f -

   • <dir_custom_environment_files> をオーバークラウドのデプロイメントで使用する環境ファイルが含まれるディレクトリーに置き換えます。ConfigMap オブジェクトは、これらを個別の data エントリーとして保存します。

2. heat-env-config ConfigMap オブジェクトに必要な環境ファイルがすべて含まれていることを確認します。

   $ oc get configmap/<configmap_name> -n openstack

手順

1. OpenStackBaremetalSet CRD を使用して Compute ノードを作成します。詳細は、OpenStackBaremetalSet CRD を使用した Compute ノードの作成を 参照してください。
2. OpenStackConfigGenerator CRD を使用して、オーバークラウド設定用の Ansible Playbook を作成します。詳細は、OpenStackConfigGenerator CRD を使用したオーバークラウド設定用の Ansible Playbook の作成 を参照してください。
3. オーバークラウドのオペレーティングシステムを登録します。詳細は、オーバークラウドのオペレーティングシステムの登録 を参照してください。
4. オーバークラウド設定を適用します。詳細は、director Operator を使用したオーバークラウド設定の適用 を参照してください。

手順

1. openstackclient のリモートシェルにアクセスします。

   $ oc rsh -n openstack openstackclient

2. cloud-admin ホームディレクトリーに移動します。

   $ cd /home/cloud-admin

3. openstack コマンドを実行します。たとえば、以下のコマンドを使用して default ネットワークを作成できます。

   $ openstack network create default

手順

1. オプション: admin ユーザーとしてログインするには、tripleo-passwords シークレットにある AdminPassword パラメーターから admin パスワードを取得します。

   $ oc get secret tripleo-passwords -o jsonpath='{.data.tripleo-overcloud-passwords\.yaml}' | base64 -d

2. OpenStackNetConfig CR からコントロールプレーン用に予約されている IP アドレスを取得します。

   spec:
     ...
     reservations:
       controlplane:
         ipReservations:
           ctlplane: 172.22.0.110
           external: 10.0.0.10
           internal_api: 172.17.0.10
           storage: 172.18.0.10
           storage_mgmt: 172.19.0.10

3. Web ブラウザーを開きます。
4. URL フィールドにコントロールプレーンの IP アドレスを入力します。
5. ユーザー名とパスワードを使用して Dashboard にログインします。

手順

1. openshift-machine-api namespace の準備ができている状態にあるホストが十分に存在することを確認します。

   $ oc get baremetalhosts -n openshift-machine-api

   ベアメタルホストの管理の詳細は、ベアメタルホストの管理 を参照してください。

2. Icompute OpenStackBaremetalSet リソースの count パラメーターの値を増やします。

   $ oc patch openstackbaremetalset compute --type=merge --patch '{"spec":{"count":3}}' -n openstack

   OpenStackBaremetalSet リソースは、Red Hat Enterprise Linux のベースオペレーティングシステムで新規ノードを自動的にプロビジョニングします。

3. プロビジョニングプロセスが完了するまで待ちます。ノードを定期的にチェックし、ノードの readiness を判別します。

   $ oc get baremetalhosts -n openshift-machine-api
   $ oc get openstackbaremetalset

4. OpenStackConfigGenerator を使用して Ansible Playbook を生成し、オーバークラウド設定を適用します。詳細は、director Operator を使用したオーバークラウドの設定とデプロイ を参照してください。

手順

1. openstackclient のリモートシェルにアクセスします。

   $ oc rsh -n openstack openstackclient

2. 削除する Compute ノードを特定します。

   $ openstack compute service list

3. ノード上の Compute サービスを無効にして、ノードが新しいインスタンスをスケジュールできないようにします。

   $ openstack compute service set <hostname> nova-compute --disable

4. Metal ³ がノードを起動しないようにベアメタルノードにアノテーションを付けます。

   $ oc annotate baremetalhost <node> baremetalhost.metal3.io/detached=true
   $ oc logs --since=1h <metal3-pod> metal3-baremetal-operator | grep -i detach
   $ oc get baremetalhost <node> -o json | jq .status.operationalStatus
   "detached"

   • <node> を BareMetalHost リソースの名前に置き換えます。
   • <metal3-pod> を metal3 Pod の名前に置き換えます。

5. root ユーザーとしてコンピュートノードにログインし、ベアメタルノードをシャットダウンします。

   [root@compute-0 ~]# shutdown -h now

   コンピュートノードにアクセスできない場合は、次の手順を実行します。

   1. コントローラーノードに root ユーザーとしてログインします。

   2. インスタンス HA が有効になっている場合は、コンピュートノードの STONITH デバイスを無効にします。

      [root@controller-0 ~]# pcs stonith disable <stonith_resource_name>

      • <stonith_resource_name> は、ノードに対応する STONITH リソースの名前に置き換えます。リソース名には <resource_agent>-<host_mac> 形式が使用されます。リソースエージェントおよびホストの MAC アドレスは、fencing.yaml ファイルの FencingConfig セクションに記載されています。
   3. IPMI を使用してベアメタルノードの電源をオフにします。詳細は、ハードウェアベンダーのドキュメントを参照してください。

6. 削除するノードに対応する BareMetalHost リソースを取得します。

   $ oc get openstackbaremetalset compute -o json | jq '.status.baremetalHosts | to_entries[] | "\(.key) => \(.value | .hostRef)"'
   "compute-0, openshift-worker-3"
   "compute-1, openshift-worker-4"

7. OpenStackBaremetalSet リソースの annotatedForDeletion パラメーターのステータスを true に変更するには、BareMetalHost リソースに osp-director.openstack.org/delete-host=true のアノテーションを付けます。

   $ oc annotate -n openshift-machine-api bmh/openshift-worker-3 osp-director.openstack.org/delete-host=true --overwrite

8. オプション: OpenStackBaremetalSet リソースで annotatedForDeletion ステータスが true に変更されたことを確認します。

   $ oc get openstackbaremetalset compute -o json -n openstack | jq .status
   {
     "baremetalHosts": {
       "compute-0": {
         "annotatedForDeletion": true,
         "ctlplaneIP": "192.168.25.105/24",
         "hostRef": "openshift-worker-3",
         "hostname": "compute-0",
         "networkDataSecretName": "compute-cloudinit-networkdata-openshift-worker-3",
         "provisioningState": "provisioned",
         "userDataSecretName": "compute-cloudinit-userdata-openshift-worker-3"
       },
       "compute-1": {
         "annotatedForDeletion": false,
         "ctlplaneIP": "192.168.25.106/24",
         "hostRef": "openshift-worker-4",
         "hostname": "compute-1",
         "networkDataSecretName": "compute-cloudinit-networkdata-openshift-worker-4",
         "provisioningState": "provisioned",
         "userDataSecretName": "compute-cloudinit-userdata-openshift-worker-4"
       }
     },
     "provisioningStatus": {
       "readyCount": 2,
       "reason": "All requested BaremetalHosts have been provisioned",
       "state": "provisioned"
     }
   }

9. compute OpenStackBaremetalSet リソースの count パラメーターの値を増やします。

   $ oc patch openstackbaremetalset compute --type=merge --patch '{"spec":{"count":1}}' -n openstack

   OpenStackBaremetalSet リソースのリソース数を減らすと、対応するコントローラーがリソースの削除を処理するようトリガーされ、以下のアクションが発生します。

   • director Operator は、削除されたノードの対応する IP 予約を OpenStackIPSet および OpenStackNetConfig から削除します。

   • director Operator は、OpenStackNet リソースの IP 予約エントリーを削除済みとしてフラグします。

     $ oc get osnet ctlplane -o json -n openstack | jq .reservations
     {
       "compute-0": {
         "deleted": true,
         "ip": "172.22.0.140"
       },
       "compute-1": {
         "deleted": false,
         "ip": "172.22.0.100"
       },
       "controller-0": {
         "deleted": false,
         "ip": "172.22.0.120"
       },
       "controlplane": {
         "deleted": false,
         "ip": "172.22.0.110"
       },
       "openstackclient-0": {
         "deleted": false,
         "ip": "172.22.0.251"
       }

10. オプション: 削除された OpenStackBaremetalSet リソースの IP 予約を他のロールが使用できるようにするには、OpenStackNetConfig オブジェクトで spec.preserveservations パラメーターの値を false に設定します。

11. openstackclient のリモートシェルにアクセスします。

    $ oc rsh openstackclient -n openstack

12. オーバークラウドから Compute サービスエントリーを削除します。

    $ openstack compute service list
    $ openstack compute service delete <service-id>

13. オーバークラウドの Compute ネットワークエージェントエントリーをチェックして、このようなエントリーが存在する場合は削除します。

    $ openstack network agent list
    $ for AGENT in $(openstack network agent list --host <scaled-down-node> -c ID -f value) ; do openstack network agent delete $AGENT ; done

14. openstackclient を終了します。

    $ exit

1. RHOSP 環境を Red Hat Enterprise Linux (RHEL)リリースにロックします。
2. RHOSP リポジトリーを更新します。
3. コンテナーイメージ準備ファイルを更新します。
4. オーバークラウドでフェンシングを無効にします。

手順

1. osconfiggenerator-update-prepare.yaml という OpenStackConfigGenerator リソースを作成します。

   $ cat <<EOF > osconfiggenerator-update-prepare.yaml
   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackConfigGenerator
   metadata:
     name: "update"
     namespace: openstack
   spec:
     gitSecret: git-secret
     enableFencing: false
     heatEnvs:
       - lifecycle/update-prepare.yaml
     heatEnvConfigMap: heat-env-config-update
     tarballConfigMap: tripleo-tarball-config-update
   EOF

2. 設定を適用します。

   $ oc apply -f osconfiggenerator-update-prepare.yaml

3. 更新の準備プロセスが完了するまで待ちます。

手順

1. osdeploy-ovn-update.yaml という名前の OpenStackDeploy カスタムリソース(CR)を作成します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: ovn-update
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: update
     advancedSettings:
       tags:
         - ovn

2. 更新された設定を適用します。

   $ oc apply -f osdeploy-ovn-update.yaml

3. ovn-controller コンテナーの更新が完了するまで待ちます。

手順

1. osdeploy-controller-update.yaml という名前の OpenStackDeploy カスタムリソース(CR)を作成します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: controller-update
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: update
     advancedSettings:
       limit: Controller

2. 更新された設定を適用します。

   $ oc apply -f osdeploy-controller-update.yaml

3. コントローラーノードの更新が完了するまで待ちます。

手順

1. osdeploy-compute-update.yaml という名前の OpenStackDeploy CR を作成します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: compute-update
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: update
     advancedSettings:
       limit: Compute

2. 更新された設定を適用します。

   $ oc apply -f osdeploy-compute-update.yaml

3. コンピュートノードの更新が完了するまで待ちます。

手順

1. osdeploy-computehci-update.yaml という名前の OpenStackDeploy CR を作成します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: computehci-update
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: update
     advancedSettings:
       limit: ComputeHCI

2. 更新された設定を適用します。

   $ oc apply -f osdeploy-computehci-update.yaml

3. ComputeHCI ノードの更新が完了するまで待ちます。

4. osdeploy-ceph-update.yaml という名前の OpenStackDeploy CR を作成します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: ceph-update
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: external-update
     advancedSettings:
       tags:
         - ceph

5. 更新された設定を適用します。

   $ oc apply -f osdeploy-ceph-update.yaml

6. Red Hat Ceph Storage ノードの更新が完了するまで待ちます。

手順

1. osdeploy-cephstorage-update.yaml という名前の OpenStackDeploy カスタムリソース(CR)を作成します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: cephstorage-update
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: update
     advancedSettings:
       limit: CephStorage

2. 更新された設定を適用します。

   $ oc apply -f osdeploy-cephstorage-update.yaml

3. Red Hat Ceph Storage ノードの更新が完了するまで待ちます。

4. osdeploy-ceph-update.yaml という名前の OpenStackDeploy CR を作成します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: ceph-update
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: external-update
     advancedSettings:
       tags:
         - ceph

5. 更新された設定を適用します。

   $ oc apply -f osdeploy-ceph-update.yaml

6. Red Hat Ceph Storage ノードの更新が完了するまで待ちます。

手順

1. openstackclient Pod のリモートシェルにアクセスします。

   $ oc rsh openstackclient

2. コントローラーノードにログインします。

   $ ssh <controller-0.ctlplane>

   • <controller-0.ctlplane> をコントローラーノードの名前に置き換えます。

3. cephadm シェルにログインします。

   [cloud-admin@controller-0 ~]$ sudo cephadm shell

4. cephadm を使用して Red Hat Ceph Storage クラスターをアップグレードします。詳細は、Red Hat Ceph Storage 5 アップグレードガイド の cephadm を使用して Red Hat Ceph Storage クラスターをアップグレードする を参照してください。

5. openstackclient Pod のリモートシェルを終了します。

   $ exit

手順

1. osdeploy-online-migration.yaml という名前の OpenStackDeploy カスタムリソース(CR)を作成します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackDeploy
   metadata:
     name: online-migration
   spec:
     configVersion: <config_version>
     configGenerator: update
     mode: external-update
     advancedSettings:
       tags:
         - online_upgrade

2. 更新された設定を適用します。

   $ oc apply -f osdeploy-online-migration.yaml

手順

1. openstackclient Pod のリモートシェルにアクセスします。

   $ oc rsh openstackclient

2. コントローラーノードにログインし、Pacemaker コマンドを実行してフェンシングを再度有効にします。

   $ ssh <controller-0.ctlplane> "sudo pcs property set stonith-enabled=true"

   • <controller-0.ctlplane> をコントローラーノードの名前に置き換えます。

3. openstackclient Pod のリモートシェルを終了します。

   $ exit

手順

1. CA 証明書を保存するための ConfigMap リソースを作成します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cacerts
     namespace: openstack
   data:
    local_CA: |
       -----BEGIN CERTIFICATE-----
       …
      -----END CERTIFICATE-----
     another_CA: |
       -----BEGIN CERTIFICATE-----
       …
      -----END CERTIFICATE-----

2. OpenStackControlPlane リソースを作成し、ConfigMap リソースを参照します。

   apiVersion: osp-director.openstack.org/v1beta2
   kind: OpenStackControlPlane
   metadata:
     name: <overcloud>
     namespace: openstack
   spec:
     caConfigMap: cacerts

   • <overcloud> をオーバークラウドのコントロールプレーンの名前に置き換えます。
3. ~/custom_environment_files ディレクトリーに tls-certs.yaml という名前のファイルを作成します。このファイルは、SSLCertificate、SSLIntermediateCertificate、SSLKey、および CAMap パラメーターを使用して、デプロイメント用に生成された証明書を指定します。

4. heatEnvConfigMap を更新して tls-certs.yaml ファイルを追加します。

   $ oc create configmap -n openstack heat-env-config --from-file=~/custom_environment_files/ --dry-run=client -o yaml | oc apply -f -

5. OpenStackConfigGenerator リソースを作成し、必要な heatEnvs 設定ファイルを追加して、パブリックエンドポイント IP の TLS を設定します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackConfigGenerator
   …
   spec:
     …
     heatEnvs:
       - ssl/tls-endpoints-public-ip.yaml
       - ssl/enable-tls.yaml
     …
     heatEnvConfigMap: heat-env-config
     tarballConfigMap: tripleo-tarball-config

6. OpenStackConfigGenerator を使用して Ansible Playbook を生成し、オーバークラウド設定を適用します。詳細は、director Operator を使用したオーバークラウドの設定とデプロイ を参照してください。

手順

1. CA 証明書を保存するための ConfigMap リソースを作成します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cacerts
     namespace: openstack
   data:
    local_CA: |
       -----BEGIN CERTIFICATE-----
       …
      -----END CERTIFICATE-----
     another_CA: |
       -----BEGIN CERTIFICATE-----
       …
      -----END CERTIFICATE-----

2. OpenStackControlPlane リソースを作成し、ConfigMap リソースを参照します。

   apiVersion: osp-director.openstack.org/v1beta2
   kind: OpenStackControlPlane
   metadata:
     name: <overcloud>
     namespace: openstack
   spec:
     caConfigMap: cacerts

   • <overcloud> をオーバークラウドのコントロールプレーンの名前に置き換えます。
3. ~/custom_environment_files ディレクトリーに tls-certs.yaml という名前のファイルを作成します。このファイルは、SSLCertificate、SSLIntermediateCertificate、SSLKey、および CAMap パラメーターを使用して、デプロイメント用に生成された証明書を指定します。

4. heatEnvConfigMap を更新して tls-certs.yaml ファイルを追加します。

   $ oc create configmap -n openstack heat-env-config --from-file=~/custom_environment_files/ --dry-run=client -o yaml | oc apply -f -

5. OpenStackConfigGenerator リソースを作成し、必要な heatEnvs 設定ファイルを追加して、パブリックエンドポイント DNS 名の TLS を設定します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackConfigGenerator
   …
   spec:
     …
     heatEnvs:
       - ssl/tls-endpoints-public-dns.yaml
       - ssl/enable-tls.yaml
     …
     heatEnvConfigMap: heat-env-config
     tarballConfigMap: tripleo-tarball-config

6. OpenStackConfigGenerator を使用して Ansible Playbook を生成し、オーバークラウド設定を適用します。詳細は、director Operator を使用したオーバークラウドの設定とデプロイ を参照してください。

手順

1. 現在の Tripleo-passwords シークレットのバックアップを作成します。

   $ oc get secret tripleo-passwords -n openstack -o yaml > tripleo-passwords_backup.yaml

2. Tripleo-overcloud-passwords_preserve_list という名前のプレインテキストファイルを作成して、次のサービスのパスワードをローテーションしないように指定します。

   parameter_defaults
   BarbicanSimpleCryptoKek
   KeystoneCredential0
   KeystoneCredential1
   KeystoneFernetKey0
   KeystoneFernetKey1
   KeystoneFernetKeys
   CephClientKey
   CephClusterFSID
   CephManilaClientKey
   CephRgwKey
   HeatAuthEncryptionKey
   MysqlClustercheckPassword
   MysqlMariabackupPassword
   PacemakerRemoteAuthkey
   PcsdPassword

   パスワードを保持したいサービスが他にもある場合は、そのサービスをリストに追加できます。

3. 変更すべきでないパスワードをリストするためのパスワードパラメーターファイル (Tripleo-overcloud-passwords.yaml) を作成します。

   $ oc get secret tripleo-passwords -n openstack \
   -o jsonpath='{.data.tripleo-overcloud-passwords\.yaml}' \
   | base64 -d | grep -f ./tripleo-overcloud-passwords_preserve_list > tripleo-overcloud-passwords.yaml

4. Tripleo-overcloud-passwords.yaml ファイルに、ローテーションしないパスワードが含まれていることを検証します。

5. tripleo-password シークレットを更新します。

   $ oc create secret generic tripleo-passwords -n openstack \
   --from-file=./tripleo-overcloud-passwords.yaml \
   --dry-run=client -o yaml | oc apply -f -

6. Ansible Playbook を作成し、OpenStackConfigGenerator CRD を使用してオーバークラウドを設定します。詳細は、OpenStackConfigGenerator CRD を使用したオーバークラウド設定用の Ansible Playbook の作成 を参照してください。
7. 更新された設定を適用します。詳細は、director Operator を使用したオーバークラウド設定の適用 を参照してください。

1. 更新されたシークレットからパスワードを取得します。

   $ oc get secret tripleo-passwords -n openstack -o jsonpath='{.data.tripleo-overcloud-passwords\.yaml}' | base64 -d | grep NovaPassword

   出力例:

   NovaPassword: hp4xpt7t2p79ktqjjnxpqwbp6

2. コントローラーノード上で稼働している Compute サービス (nova) のパスワードを取得します。

   1. openstackclient リモートシェルにアクセスします。

      $ oc rsh openstackclient -n openstack

   2. ホームディレクトリーにいることを確認します。

      $ cd

   3. Compute サービスのパスワードを取得します。

      $ ansible -i /home/cloud-admin/ctlplane-ansible-inventory Controller -b -a "grep ^connection /var/lib/config-data/puppet-generated/nova/etc/nova/nova.conf"

      出力例:

      172.22.0.120 | CHANGED | rc=0 >> connection=mysql+pymysql://nova_api:hp4xpt7t2p79ktqjjnxpqwbp6@172.17.0.10/nova_api?read_default_file=/etc/my.cnf.d/tripleo.cnf&read_default_group=tripleo connection=mysql+pymysql://nova:hp4xpt7t2p79ktqjjnxpqwbp6@172.17.0.10/nova?read_default_file=/etc/my.cnf.d/tripleo.cnf&read_default_group=tripleo

手順

1. openstacknetconfig.yaml という名前の設定ファイルを作成します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackNetConfig
   metadata:
     name: openstacknetconfig
   spec:
     attachConfigurations:
       br-osp:
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp7s0
               description: Linux bridge with enp7s0 as a port
               name: br-osp
               state: up
               type: linux-bridge
               mtu: 1500
       br-ex:
         nodeNetworkConfigurationPolicy:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
           desiredState:
             interfaces:
             - bridge:
                 options:
                   stp:
                     enabled: false
                 port:
                 - name: enp6s0
               description: Linux bridge with enp6s0 as a port
               name: br-ex
               state: up
               type: linux-bridge
               mtu: 1500
     # optional DnsServers list
     dnsServers:
     - 192.168.25.1
     # optional DnsSearchDomains list
     dnsSearchDomains:
     - osptest.test.metalkube.org
     - some.other.domain
     # DomainName of the OSP environment
     domainName: osptest.test.metalkube.org
     networks:
     - name: Control
       nameLower: ctlplane
       subnets:
       - name: ctlplane
         ipv4:
           allocationEnd: 192.168.25.250
           allocationStart: 192.168.25.100
           cidr: 192.168.25.0/24
           gateway: 192.168.25.1
         attachConfiguration: br-osp
     - name: InternalApi
       nameLower: internal_api
       mtu: 1350
       subnets:
       - name: internal_api
         ipv4:
           allocationEnd: 172.17.0.250
           allocationStart: 172.17.0.10
           cidr: 172.17.0.0/24
           routes:
           - destination: 172.17.1.0/24
             nexthop: 172.17.0.1
           - destination: 172.17.2.0/24
             nexthop: 172.17.0.1
         vlan: 20
         attachConfiguration: br-osp
       - name: internal_api_leaf1
         ipv4:
           allocationEnd: 172.17.1.250
           allocationStart: 172.17.1.10
           cidr: 172.17.1.0/24
           routes:
           - destination: 172.17.0.0/24
             nexthop: 172.17.1.1
           - destination: 172.17.2.0/24
             nexthop: 172.17.1.1
         vlan: 21
         attachConfiguration: br-osp
       - name: internal_api_leaf2
         ipv4:
           allocationEnd: 172.17.2.250
           allocationStart: 172.17.2.10
           cidr: 172.17.2.0/24
           routes:
           - destination: 172.17.1.0/24
             nexthop: 172.17.2.1
           - destination: 172.17.0.0/24
             nexthop: 172.17.2.1
         vlan: 22
         attachConfiguration: br-osp
     - name: External
       nameLower: external
       subnets:
       - name: external
         ipv4:
           allocationEnd: 10.0.0.250
           allocationStart: 10.0.0.10
           cidr: 10.0.0.0/24
           gateway: 10.0.0.1
         attachConfiguration: br-ex
     - name: Storage
       nameLower: storage
       mtu: 1350
       subnets:
       - name: storage
         ipv4:
           allocationEnd: 172.18.0.250
           allocationStart: 172.18.0.10
           cidr: 172.18.0.0/24
           routes:
           - destination: 172.18.1.0/24
             nexthop: 172.18.0.1
           - destination: 172.18.2.0/24
             nexthop: 172.18.0.1
         vlan: 30
         attachConfiguration: br-osp
       - name: storage_leaf1
         ipv4:
           allocationEnd: 172.18.1.250
           allocationStart: 172.18.1.10
           cidr: 172.18.1.0/24
           routes:
           - destination: 172.18.0.0/24
             nexthop: 172.18.1.1
           - destination: 172.18.2.0/24
             nexthop: 172.18.1.1
         vlan: 31
         attachConfiguration: br-osp
       - name: storage_leaf2
         ipv4:
           allocationEnd: 172.18.2.250
           allocationStart: 172.18.2.10
           cidr: 172.18.2.0/24
           routes:
           - destination: 172.18.0.0/24
             nexthop: 172.18.2.1
           - destination: 172.18.1.0/24
             nexthop: 172.18.2.1
         vlan: 32
         attachConfiguration: br-osp
     - name: StorageMgmt
       nameLower: storage_mgmt
       mtu: 1350
       subnets:
       - name: storage_mgmt
         ipv4:
           allocationEnd: 172.19.0.250
           allocationStart: 172.19.0.10
           cidr: 172.19.0.0/24
           routes:
           - destination: 172.19.1.0/24
             nexthop: 172.19.0.1
           - destination: 172.19.2.0/24
             nexthop: 172.19.0.1
         vlan: 40
         attachConfiguration: br-osp
       - name: storage_mgmt_leaf1
         ipv4:
           allocationEnd: 172.19.1.250
           allocationStart: 172.19.1.10
           cidr: 172.19.1.0/24
           routes:
           - destination: 172.19.0.0/24
             nexthop: 172.19.1.1
           - destination: 172.19.2.0/24
             nexthop: 172.19.1.1
         vlan: 41
         attachConfiguration: br-osp
       - name: storage_mgmt_leaf2
         ipv4:
           allocationEnd: 172.19.2.250
           allocationStart: 172.19.2.10
           cidr: 172.19.2.0/24
           routes:
           - destination: 172.19.0.0/24
             nexthop: 172.19.2.1
           - destination: 172.19.1.0/24
             nexthop: 172.19.2.1
         vlan: 42
         attachConfiguration: br-osp
     - name: Tenant
       nameLower: tenant
       vip: False
       mtu: 1350
       subnets:
       - name: tenant
         ipv4:
           allocationEnd: 172.20.0.250
           allocationStart: 172.20.0.10
           cidr: 172.20.0.0/24
           routes:
           - destination: 172.20.1.0/24
             nexthop: 172.20.0.1
           - destination: 172.20.2.0/24
             nexthop: 172.20.0.1
         vlan: 50
         attachConfiguration: br-osp
       - name: tenant_leaf1
         ipv4:
           allocationEnd: 172.20.1.250
           allocationStart: 172.20.1.10
           cidr: 172.20.1.0/24
           routes:
           - destination: 172.20.0.0/24
             nexthop: 172.20.1.1
           - destination: 172.20.2.0/24
             nexthop: 172.20.1.1
         vlan: 51
         attachConfiguration: br-osp
       - name: tenant_leaf2
         ipv4:
           allocationEnd: 172.20.2.250
           allocationStart: 172.20.2.10
           cidr: 172.20.2.0/24
           routes:
           - destination: 172.20.0.0/24
             nexthop: 172.20.2.1
           - destination: 172.20.1.0/24
             nexthop: 172.20.2.1
         vlan: 52
         attachConfiguration: br-osp

2. 内部 API ネットワークを作成します。

   $ oc create -f openstacknetconfig.yaml -n openstack

3. OpenStackNetConfig リソースのリソースと子リソースが作成されていることを確認します。

   $ oc get openstacknetconfig/openstacknetconfig -n openstack
   $ oc get openstacknetattachment -n openstack
   $ oc get openstacknet -n openstack

手順

1. roles_data.yaml ファイルを更新します。

   ...
   ###############################################################################
   # Role: ComputeLeaf1                                                          #
   ###############################################################################
   - name: ComputeLeaf1
     description: |
       Basic ComputeLeaf1 Node role
     # Create external Neutron bridge (unset if using ML2/OVS without DVR)
     tags:
       - compute
       - external_bridge
     networks:
       InternalApi:
         subnet: internal_api_leaf1
       Tenant:
         subnet: tenant_leaf1
       Storage:
         subnet: storage_leaf1
     HostnameFormatDefault: '%stackname%-novacompute-leaf1-%index%'
   ...
   ###############################################################################
   # Role: ComputeLeaf2                                                          #
   ###############################################################################
   - name: ComputeLeaf2
     description: |
       Basic ComputeLeaf1 Node role
     # Create external Neutron bridge (unset if using ML2/OVS without DVR)
     tags:
       - compute
       - external_bridge
     networks:
       InternalApi:
         subnet: internal_api_leaf2
       Tenant:
         subnet: tenant_leaf2
       Storage:
         subnet: storage_leaf2
     HostnameFormatDefault: '%stackname%-novacompute-leaf2-%index%'
   ...

2. Compute ロールごとに NIC テンプレートを作成します。Ansible NIC テンプレートの例は、https://github.com/openstack/tripleo-ansible/tree/stable/wallaby/tripleo_ansible/roles/tripleo_network_config/templates を参照してください。

3. 新しいノードの NIC テンプレートを環境ファイルに追加します。

   parameter_defaults:
     ComputeNetworkConfigTemplate: 'multiple_nics_vlans_dvr.j2'
     ComputeLeaf1NetworkConfigTemplate: 'multiple_nics_vlans_dvr.j2'
     ComputeLeaf2NetworkConfigTemplate: 'multiple_nics_compute_leaf_2_vlans_dvr.j2'

4. ~/custom_environment_files ディレクトリーで、roles_data.yaml ファイル、環境ファイル、NIC テンプレートを tarball にアーカイブします。

   $ tar -cvzf custom-spine-leaf-config.tar.gz *.yaml

5. tripleo-tarball-config ConfigMap リソースを作成します。

   $ oc create configmap tripleo-tarball-config --from-file=custom-spine-leaf-config.tar.gz -n openstack

手順

1. ワークステーションに openstack-controller.yaml という名前のファイルを作成します。コントローラーノードのリソース仕様を含めます。次の例は、3 つのコントローラーノードで設定されるコントロールプレーンの仕様を示しています。

   apiVersion: osp-director.openstack.org/v1beta2
   kind: OpenStackControlPlane
   metadata:
     name: overcloud
     namespace: openstack
   spec:
     gitSecret: git-secret
     openStackClientImageURL: registry.redhat.io/rhosp-rhel9/openstack-tripleoclient:17.1
     openStackClientNetworks:
       - ctlplane
       - external
       - internal_api
       - internal_api_leaf1 # optionally the openstackclient can also be connected to subnets
     openStackClientStorageClass: host-nfs-storageclass
     passwordSecret: userpassword
     domainName: ostest.test.metalkube.org
     virtualMachineRoles:
       Controller:
         roleName: Controller
         roleCount: 1
         networks:
           - ctlplane
           - internal_api
           - external
           - tenant
           - storage
           - storage_mgmt
         cores: 6
         memory: 20
         rootDisk:
           diskSize: 50
           baseImageVolumeName: openstack-base-img
           storageClass: host-nfs-storageclass
           storageAccessMode: ReadWriteMany
           storageVolumeMode: Filesystem
     enableFencing: False

2. コントロールプレーンを作成します。

   $ oc create -f openstack-controller.yaml -n openstack

3. Red Hat OpenShift Container Platform (RHOCP) が OpenStackControlPlane リソースに関連するリソースを作成するまで待ちます。

4. Compute リーフごとにワークステーション上にファイル (例: openstack-computeleaf1.yaml) を作成します。リーフの Compute ノードのリソース仕様を含めます。次の例は、1 つの Compute ノードを含む 1 つの計算リーフの仕様を示しています。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackBaremetalSet
   metadata:
     name: computeleaf1
     namespace: openstack
   spec:
     # How many nodes to provision
     count: 1
     # The image to install on the provisioned nodes
     baseImageUrl: http://<source_host>/rhel-9.2-x86_64-kvm.qcow2
     # The secret containing the SSH pub key to place on the provisioned nodes
     deploymentSSHSecret: osp-controlplane-ssh-keys
     # The interface on the nodes that will be assigned an IP from the mgmtCidr
     ctlplaneInterface: enp7s0
     # Networks to associate with this host
     networks:
           - ctlplane
           - internal_api_leaf1
           - external
           - tenant_leaf1
           - storage_leaf1
     roleName: ComputeLeaf1
     passwordSecret: userpassword

5. 各リーフの Compute ノードを作成します。

   $ oc create -f openstack-computeleaf1.yaml -n openstack

6. OpenStackConfigGenerator を使用して Ansible Playbook を生成し、オーバークラウド設定を適用します。詳細は、director Operator を使用したオーバークラウドの設定とデプロイ を参照してください。

検証

1. コントロールプレーンのリソースを表示します。

   $ oc get openstackcontrolplane/overcloud -n openstack

2. OpenStackVMSet リソースを表示して、コントロールプレーンの仮想マシン (VM) セットの作成を確認します。

   $ oc get openstackvmsets -n openstack

3. VM リソースを表示して、OpenShift Virtualization でのコントロールプレーン VM の作成を確認します。

   $ oc get virtualmachines

4. openstackclient Pod リモートシェルへのアクセスをテストします。

   $ oc rsh -n openstack openstackclient

5. 各 Compute リーフのリソースを表示します。

   $ oc get openstackbaremetalset/computeleaf1 -n openstack

6. RHOCP によって管理されるベアメタルマシンを表示して、Compute ノードの作成を確認します。

   $ oc get baremetalhosts -n openshift-machine-api

手順

1. ワークステーション上に openstack_backup.yaml という名前のファイルを作成します。

2. 以下の設定を openstack_backup.yaml ファイルに追加して、OpenStackBackupRequest カスタムリソース (CR) を作成します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackBackupRequest
   metadata:
     name: openstackbackupsave
     namespace: openstack
   spec:
     mode: save 1
     additionalConfigMaps: [] 2
     additionalSecrets: [] 3

   1

   OpenStackBackup CR の作成を要求するには、mode を save に設定します。

   2

   オプション: 手動で作成した ConfigMap リソースを含めます。

   3

   オプション: 手動で作成した Secret リソースを含めます。

   注記

   OSPdO は、OpenStackControlPlane や OpenStackBaremetalSet など、OSPdO CR に関連付けられたすべての ConfigMap オブジェクトと Secret オブジェクトを名前空間に含めようとします。これらを追加リストに含める必要はありません。

3. openstack_backup.yaml ファイルを保存します。

4. OpenStackBackupRequest CR を作成します。

   $ oc create -f openstack_backup.yaml -n openstack

5. OpenStackBackupRequest CR の作成ステータスを監視します。

   $ oc get openstackbackuprequest openstackbackupsave -n openstack

   • Quiescing 状態は、OSPdO が CR が終了状態に達するのを待っていることを示します。CR の数は、バックアップの作成が完了するまでにかかる時間に影響を与える可能性があります。

     NAME                     OPERATION   SOURCE   STATUS      COMPLETION TIMESTAMP
     openstackbackupsave      save                 Quiescing

     ステータスが予想よりも長く Quiescing 状態のままである場合は、OSPdO ログを調査して進行状況を確認できます。

     $ oc logs <operator_pod> -c manager -f
     2022-01-11T18:26:15.180Z        INFO    controllers.OpenStackBackupRequest      Quiesce for save for OpenStackBackupRequest openstackbackupsave is waiting for: [OpenStackBaremetalSet: compute, OpenStackControlPlane: overcloud, OpenStackVMSet: controller]

     • <operator_pod> を Operator Pod の名前に置き換えます。

   • Saved 状態は、OpenStackBackup CR が作成されたことを示します。

     NAME                     OPERATION   SOURCE   STATUS   COMPLETION TIMESTAMP
     openstackbackupsave      save                 Saved    2022-01-11T19:12:58Z

   • Error 状態は、バックアップの作成に失敗したことを示します。リクエストの内容を確認してエラーを見つけます。

     $ oc get openstackbackuprequest openstackbackupsave -o yaml -n openstack

6. OpenStackBackup リソースを表示して、存在することを確認します。

   $ oc get openstackbackup -n openstack
   NAME                                AGE
   openstackbackupsave-1641928378      6m7s

手順

1. 利用可能なバックアップを一覧表示します。

   $ oc get osbackup

2. 特定のバックアップの詳細を調べます。

   $ oc get backup <name> -o yaml

   • <name> を検査するバックアップの名前に置き換えます。
3. ワークステーション上に openstack_restore.yaml という名前のファイルを作成します。

4. 以下の設定を openstack_restore.yaml ファイルに追加して、OpenStackBackupRequest カスタムリソース (CR) を作成します。

   apiVersion: osp-director.openstack.org/v1beta1
   kind: OpenStackBackupRequest
   metadata:
     name: openstackbackuprestore
     namespace: openstack
   spec:
     mode: <mode>
     restoreSource: <restore_source>

   • <mode> を次のいずれかのオプションに置き換えます。

     • restore: 既存の OpenStackBackup からのリストアを要求します。
     • cleanRestore: 既存の OpenStackBackup から新しいリソースを復元して作成する前に、namespace 内の既存の OSPdO リソースを完全に消去します。
   • <restore_source> を復元する OpenStackBackup の ID に置き換えます (例: openstackbackupsave-1641928378)。
5. openstack_restore.yaml ファイルを保存します。

6. OpenStackBackupRequest CR を作成します。

   $ oc create -f openstack_restore.yaml -n openstack

7. OpenStackBackupRequest CR の作成ステータスを監視します。

   $ oc get openstackbackuprequest openstackbackuprestore -n openstack

   • Loading 状態は、OpenStackBackup のすべてのリソースがクラスターに対して適用されていることを示します。

     NAME                     OPERATION  SOURCE                           STATUS     COMPLETION TIMESTAMP
     openstackbackuprestore   restore    openstackbackupsave-1641928378   Loading

   • Reconciling 状態は、すべてのリソースがロードされ、OSPdO がすべてのリソースのプロビジョニングを試みるために調整を開始したことを示します。

     NAME                     OPERATION  SOURCE                           STATUS       COMPLETION TIMESTAMP
     openstackbackuprestore   restore    openstackbackupsave-1641928378   Reconciling

   • Restored 状態は、OpenStackBackup CR が復元されたことを示します。

     NAME                     OPERATION  SOURCE                           STATUS     COMPLETION TIMESTAMP
     openstackbackuprestore   restore    openstackbackupsave-1641928378   Restored   2022-01-12T13:48:57Z

   • Error 状態は、復元が失敗したことを示します。リクエストの内容を確認してエラーを見つけます。

     $ oc get openstackbackuprequest openstackbackuprestore -o yaml -n openstack

手順

1. Controller virtualMachineRole コアの数を 8 に変更します。

   $ oc patch -n openstack osctlplane overcloud --type='json' -p='[{"op": "add", "path": "/spec/virtualMachineRoles/controller/cores", "value": 8 }]'

2. コントローラーの virtualMachineRole RAM サイズを 22GB に変更します。

   $ oc patch -n openstack osctlplane overcloud --type='json' -p='[{"op": "add", "path": "/spec/virtualMachineRoles/controller/memory", "value": 22 }]'

3. virtualMachineRole リソースを検証します。

   $ oc get osvmset
   NAME         CORES   RAM   DESIRED   READY   STATUS        REASON
   controller   8       22    1         1       Provisioned   All requested VirtualMachines have been provisioned

4. 仮想マシンの内部から、正常なシャットダウンを実行します。更新された各仮想マシンを 1 つずつシャットダウンします。

5. 仮想マシンをパワーオンします。

   $ `virtctl start <VM>` to power on the virtual machine.

   • <VM> を 仮想マシンの名前に置き換えます。

手順

1. OpenStackControlPlane オブジェクトで additionalDisks パラメーターを追加または更新します。

   spec:
     ...
     virtualMachineRoles:
       Controller:
         ...
         additionalDisks:
         - baseImageVolumeName: openstack-base-img
           dedicatedIOThread: false
           diskSize: 10
           name: "data-disk1"
           storageAccessMode: ReadWriteMany
           storageClass: host-nfs-storageclass
           storageVolumeMode: Filesystem

2. パッチを適用します。

   $ oc patch -n openstack osctlplane overcloud --patch-file controller_add_data_disk1.yaml

3. virtualMachineRole リソースを検証します。

   $ oc get osvmset controller -o json | jq .spec.additionalDisks
   [
     {
       "baseImageVolumeName": "openstack-base-img",
       "dedicatedIOThread": false,
       "diskSize": 10,
       "name": "data-disk1",
       "storageAccessMode": "ReadWriteMany",
       "storageClass": "host-nfs-storageclass",
       "storageVolumeMode": "Filesystem"
     }
   ]

4. 仮想マシンの内部から、正常なシャットダウンを実行します。更新された各仮想マシンを 1 つずつシャットダウンします。

5. 仮想マシンをパワーオンします。

   $ `virtctl start <VM>` to power on the virtual machine.

   • <VM> を 仮想マシンの名前に置き換えます。

手順

1. openstack namespace を作成します。

   $ oc new-project openstack

2. インデックスイメージを作成し、レジストリーにプッシュします。

   $ podman login registry.redhat.io
   $ podman login your.registry.local
   $ BUNDLE_IMG="registry.redhat.io/rhosp-rhel8/osp-director-operator-bundle@sha256:c19099ac3340d364307a43e0ae2be949a588fefe8fcb17663049342e7587f055"

   注記

   最新のバンドルイメージは次の場所から取得できます: Certified container images .osp-director-operator-bundle を検索します。

3. オペレータインデックスイメージに基づいて、関連するイメージをミラーリングします。

   $ oc adm catalog mirror ${INDEX_IMG} your.registry.local --insecure --index-filter-by-os='Linux/x86_64'

4. ミラーリングが完了すると、現在のディレクトリーに manifests-osp-director-operator-index-<random_number> という manifests ディレクトリーが生成されます。作成した ImageContentSourcePolicy をクラスターに適用します。

   $ os apply -f manifests-osp-director-operator-index-<random_number>/imageContentSourcePolicy.yaml

   • <random_number> をランダムに生成された数値に置き換えます。

5. osp-director-operator.yaml という名前のファイルを作成し、次の YAML コンテンツを含めて、director Operator のインストールに必要な 3 つのリソースを設定します。

   apiVersion: operators.coreos.com/v1alpha1
   kind: CatalogSource
   metadata:
     name: osp-director-operator-index
     namespace: openstack
   spec:
     sourceType: grpc
     image: your.registry.local/osp-director-operator-index:1.3.x-y
   ---
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: "osp-director-operator-group"
     namespace: openstack
   spec:
     targetNamespaces:
     - openstack
   ---
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: osp-director-operator-subscription
     namespace: openstack
   spec:
     config:
       env:
       - name: WATCH_NAMESPACE
         value: openstack,openshift-machine-api,openshift-sriov-network-operator
     source: osp-director-operator-index
     sourceNamespace: openstack
     name: osp-director-operator

6. openstack namespace に新しいリソースを作成します。

   $ oc apply -f osp-director-operator.yaml

7. 必要なオーバークラウドイメージをリポジトリーにコピーします。

   $ for i in $(podman search --limit 1000 "registry.redhat.io/rhosp-rhel9/openstack" --format="{{ .Name }}" | awk '{print $1 ":" "17.1.0"}' | awk -F "/" '{print $2 "/" $3}'); do skopeo copy --all docker://registry.redhat.io/$i docker://your.registry.local/$i;done

   注記

   Red Hat Satellite がローカルレジストリーとして使用されている場合は、コンテナーイメージ用の Satellite Server の準備 を参照できます。

8. これで、director Operator のインストールと準備 に進むことができます。

検証

1. director Operator が正常にインストールされたことを確認します。

   $ oc get operators
   NAME                                     AGE
   osp-director-operator.openstack          5m