osp director operator
v1.2.3
OSPディレクターのオペレーターは、OpenShiftの上に一連のカスタムリソース定義を作成して、TripleoのUndercloudによって通常作成されたリソースを管理します。これらのCRDは、ハードウェアプロビジョニングとソフトウェア構成の2つのタイプに分割されます。
OSPディレクターのオペレーターは、OLMオペレーターライフサイクルマネージャーを介してインストールおよび管理されています。 OLMは、OpenShiftのインストールで自動的にインストールされます。最新のOSPディレクターオペレーターのスナップショットを取得するには、OLMでインストールを促進するために、適切なCatalogSource、OperatorGroup、およびサブスクリプションを作成する必要があります。
oc new-project openstack apiVersion : operators.coreos.com/v1alpha1
kind : CatalogSource
metadata :
name : osp-director-operator-index
namespace : openstack
spec :
sourceType : grpc
image : quay.io/openstack-k8s-operators/osp-director-operator-index:0.0.1 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
startingCSV : osp-director-operator.v0.0.1
channel : alpha特定のタグのためにOLMを使用してインストールを自動化するスクリプトがあります：インストールを自動化するスクリプト
注：将来のある時点で、OPRATORHUBに統合して、OSPディレクターオペレーターがOCPインストールのデフォルトのOLMカタログソースで自動的に利用可能になるようにすることができます。
OpenStackを展開する前に、ベースRHELデータボリュームを作成します。これは、OpenShift仮想化を介してプロビジョニングされるコントローラーVMによって使用されます。これを行うためのアプローチは次のとおりです。
virtctlインストールします。 sudo subscription-manager repos --enable=cnv-2.6-for-rhel-8-x86_64-rpms
sudo dnf install -y kubevirt-virtctl
curl -O http://download.devel.redhat.com/brewroot/packages/rhel-guest-image/8.4/1168/images/rhel-guest-image-8.4-1168.x86_64.qcow2
dnf install -y libguestfs-tools-c
virt-customize -a < rhel guest image > --run-command ' sed -i -e "s/^(kernelopts=.*)net.ifnames=0 (.*)/12/" /boot/grub2/grubenv '
virt-customize -a < rhel guest image > --run-command ' sed -i -e "s/^(GRUB_CMDLINE_LINUX=.*)net.ifnames=0 (.*)/12/" /etc/default/grub '/etc/hostsに追加します。 <cluster ingress VIP> cdi-uploadproxy-openshift-cnv.apps.<cluster name>.<domain name>
virtctlを介して画像をオープンシフト仮想化にアップロードします。 virtctl image-upload dv openstack-base-img -n openstack --size=50Gi --image-path=<local path to image> --storage-class <desired storage class> --insecure
storage-classについては、次のようなものから使用したいものを選択します。 oc get storageclass
OpenStackNetConfigカスタムリソースを定義します。 CTLPlaneには、少なくとも1つのネットワークが必要です。オプションで、Tripleoのネットワーク分離アーキテクチャで使用するCR内の複数のネットワークを定義できます。ネットワークの定義に加えて、OpenStackNetには、OpenShift仮想化を介してVMをこのネットワークに添付するために使用されるネットワーク構成ポリシーを定義するために使用される情報が含まれています。以下は、ホスト構成にLinuxブリッジを使用する単純なIPv4 CTLPlaneネットワークの例です。
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
# 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
# optional: (OSP17 only) specify all phys networks with optional MAC address prefix, used to
# create static OVN Bridge MAC address mappings. Unique OVN bridge mac address per node is
# dynamically allocated by creating OpenStackMACAddress resource and create a MAC per physnet per node.
# - If PhysNetworks is not provided, the tripleo default physnet datacentre gets created.
# - If the macPrefix is not specified for a physnet, the default macPrefix "fa:16:3a" is used.
# - If PreserveReservations is not specified, the default is true.
ovnBridgeMacMappings :
preserveReservations : True
physNetworks :
- macPrefix : fa:16:3a
name : datacentre
- macPrefix : fa:16:3b
name : datacentre2
# optional: configure static mapping for the networks per nodes. If there is none, a random gets created
reservations :
controller-0 :
macReservations :
datacentre : fa:16:3a:aa:aa:aa
datacentre2 : fa:16:3b:aa:aa:aa
compute-0 :
macReservations :
datacentre : fa:16:3a:bb:bb:bb
datacentre2 : fa:16:3b:bb:bb:bb上記のYAMLをNetworkConfig.yamlというファイルに書き込む場合、このコマンドを介してOpenStackNetConfigを作成できます。
oc create -n openstack -f networkconfig.yamlVLANを使用してネットワーク分離を使用するには、VLAN IDをネットワーク定義の仕様に追加します
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-osp
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
attachConfiguration : br-osp
vlan : 20
ipv4 :
allocationEnd : 172.17.0.250
allocationStart : 172.17.0.10
cidr : 172.17.0.0/24
- name : External
nameLower : external
subnets :
- name : external
ipv6 :
allocationEnd : 2001:db8:fd00:1000:ffff:ffff:ffff:fffe
allocationStart : 2001:db8:fd00:1000::10
cidr : 2001:db8:fd00:1000::/64
gateway : 2001:db8:fd00:1000::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
vlan : 30
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
vlan : 40
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
vlan : 50
attachConfiguration : br-ospLinux-Bridgeでネットワーク分離にVLANを使用する場合
注：ブリッジにジャンボフレームを使用するには、デバイスの構成を作成して、collenct 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 : enp7s0
description : Linux bridge with enp7s0 as a port
name : br-osp
state : up
type : linux-bridge
mtu : 9000
- name : enp7s0
description : Configuring enp7s0 on workers
type : ethernet
state : up
mtu : 9000 TRIPLEOネットワーク構成に使用されるカスタムヒート環境、ヒートテンプレート、カスタムロールファイル（名前はroles_data.yamlである必要があります）を定義するconfigmapsを作成します。 Adminstratorの定義された熱環境ファイルは、ConfigMapで提供でき、OverCloud展開用のヒートスタックを作成するために使用される後の手順でコンベンションとして使用されます。コンベンションとして、各OSPディレクターのインストールは、この情報を提供するためにheat-env-configとtripleo-tarball-configという名前の2つのConfigMapsを使用します。 heat-env-config ConfigMapは、すべての展開環境ファイルを保持します。ここでは、各ファイルが-e file.yamlがopenstack stack createコマンドに追加されます。良い例は次のとおりです。
「Tarball Config Map」を使用して、PlayBookが生成されたときにTripleo-heat-Templatesで抽出される（バイナリ）ターボールを提供できます。各ターボールには、THTディレクトリのルートに関連するファイルのディレクトリを含める必要があります。カスタムタルボールを含む構成マップに、次の例のようなものを保存する必要があります。
net-configファイル。
Net-config環境
注：仮想マシンのNet-Configファイルはオペレーターによって作成されますが、「Tarball Config Map」を使用して上書きすることができます。事前にレンダリングされたNet-configを上書きするには、OSP16.2または<role lowercase>-nic-template.yaml <role lowercase>-nic-template.j2 template.yamlファイル名を使用します。注：OpenStackVMSetコントローラーによって作成されたVMのネットワークインターフェイス名は、VMロールに割り当てられたネットワーク名によってアルファベット順に順序付けられます。例外は、常に最初のインターフェイスであるVM PODのdefaultネットワークインターフェイスです。仮想マシン定義の結果の整数セクションは次のようになります。
interfaces :
- masquerade : {}
model : virtio
name : default
- bridge : {}
model : virtio
name : ctlplane
- bridge : {}
model : virtio
name : external
- bridge : {}
model : virtio
name : internalapi
- bridge : {}
model : virtio
name : storage
- bridge : {}
model : virtio
name : storagemgmt
- bridge : {}
model : virtio
name : tenantこれにより、CTLPLANEインターフェイスはNIC2、外部NIC3などです。
注：FIPトラフィックは、ML2/OVNおよびDVRを使用してVLANテナントネットワークに渡されません。 DVRはデフォルトで有効になります。 OVNを使用したVLANテナントネットワークが必要な場合は、DVRを無効にすることができます。 DVRを無効にするには、環境ファイルに次の行を含めます。
parameter_defaults :
NeutronEnableDVR : false「OVNでの分散VLANトラフィック」のサポートは、「OVNの分散VLANトラフィックのトリプルのサポートを追加」のMACアドレスの管理で追跡されています（https://bugs.launchpad.net/+bug/1881593）
[gitレポの構成マップ]この構成には、生成されたプレイブックを保存するために使用されるgitリポジトリのSSHキーとURLが含まれています（以下）
環境の上記のテンプレート/例をカスタマイズしたら、それぞれのConfigMapタイプを含むファイルにこれらの例コマンドを使用して、「Heat-Env-Config」と「Tripleo-Tarball-Config」（Tarballs）ConfigMapsの両方のConfigMapsを作成できます。 （ConfigMapの各タイプの1つのディレクトリ）：
# create the configmap for heat-env-config
oc create configmap -n openstack heat-env-config --from-file=heat-env-config/ --dry-run=client -o yaml | oc apply -f -
# create the configmap containing a tarball of t-h-t network config files. NOTE: these files may overwrite default t-h-t files so keep this in mind when naming them.
cd < dir with net config files >
tar -cvzf net-config.tar.gz * .yaml
oc create configmap -n openstack tripleo-tarball-config --from-file=tarball-config.tar.gz
# create the Git secret used for the repo where Ansible playbooks are stored
oc create secret generic git-secret -n openstack --from-file=git_ssh_identity= < path to git id_rsa > --from-literal=git_url= < your git server URL (git@...) >
（オプション）OpenStackControlPlaneの秘密を作成します。この秘密は、仮想マシンとBareMetalホストのデフォルトのパスワードを提供します。秘密が提供されていない場合、OSP-Controlplane-ssh-keysの秘密で定義されたSSHキーでのみログインできます。
apiVersion : v1
kind : Secret
metadata :
name : userpassword
namespace : openstack
data :
# 12345678
NodeRootPassword : MTIzNDU2Nzg=上記のyamlをctlplane-secret.yamlというファイルに書き込む場合、このコマンドを介して秘密を作成できます。
oc create -n openstack -f ctlplane-secret.yamlOpenStackControlPlaneカスタムリソースを定義します。 OpenStackControlPlaneカスタムリソースは、OSPコントローラーに使用されるVMを作成およびスケーリングするための中央の場所と、展開用の追加のVMSセットを提供します。基本的なデモのインストールには少なくとも1つのコントローラーVMが必要であり、OSPごとに高可用性ガイドライン3コントローラーVMが推奨されます。
注：Rhel-Guest-ImageがBaseとして使用されてOpenStackControlPlane仮想マシンを展開する場合は、Net.ifNames = 0 Kernelパラメーターを画像から削除して、BioSDEVネットワークインターフェイスの名前を付けるようにしてください。これは次のように行うことができます。
dnf install -y libguestfs-tools-c
virt-customize -a bms-image.qcow2 --run-command ' sed -i -e "s/^(kernelopts=.*)net.ifnames=0 (.*)/12/" /boot/grub2/grubenv ' apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackControlPlane
metadata :
name : overcloud
namespace : openstack
spec :
openStackClientImageURL : quay.io/openstack-k8s-operators/rhosp16-openstack-tripleoclient:16.2_20210713.1
openStackClientNetworks :
- ctlplane
- external
- internalapi
# openStackClientStorageClass must support RWX
# https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes
openStackClientStorageClass : host-nfs-storageclass
passwordSecret : userpassword
gitSecret : git-secret
virtualMachineRoles :
controller :
roleName : Controller
roleCount : 3
networks :
- ctlplane
- internalapi
- external
- tenant
- storage
- storagemgmt
cores : 6
memory : 12
rootDisk :
diskSize : 50
baseImageVolumeName : openstack-base-img
# storageClass must support RWX to be able to live migrate VMs
storageClass : host-nfs-storageclass
storageAccessMode : ReadWriteMany
# When using OpenShift Virtualization with OpenShift Container Platform Container Storage,
# specify RBD block mode persistent volume claims (PVCs) when creating virtual machine disks. With virtual machine disks,
# RBD block mode volumes are more efficient and provide better performance than Ceph FS or RBD filesystem-mode PVCs.
# To specify RBD block mode PVCs, use the 'ocs-storagecluster-ceph-rbd' storage class and VolumeMode: Block.
storageVolumeMode : Filesystem
# Optional
# DedicatedIOThread - Disks with dedicatedIOThread set to true will be allocated an exclusive thread.
# This is generally useful if a specific Disk is expected to have heavy I/O traffic, e.g. a database spindle.
dedicatedIOThread : false
additionalDisks :
# name must be uniqe and must not be rootDisk
- name : dataDisk1
diskSize : 100
storageClass : host-nfs-storageclass
storageAccessMode : ReadWriteMany
storageVolumeMode : Filesystem
# Optional block storage settings
# IOThreadsPolicy - IO thread policy for the domain. Currently valid policies are shared and auto.
# However, if any disk requests a dedicated IOThread, ioThreadsPolicy will be enabled and default to shared.
# When ioThreadsPolicy is set to auto IOThreads will also be "isolated" from the vCPUs and placed on the same physical CPU as the QEMU emulator thread.
# An ioThreadsPolicy of shared indicates that KubeVirt should use one thread that will be shared by all disk devices.
ioThreadsPolicy : auto
# Block Multi-Queue is a framework for the Linux block layer that maps Device I/O queries to multiple queues.
# This splits I/O processing up across multiple threads, and therefor multiple CPUs. libvirt recommends that the
# number of queues used should match the number of CPUs allocated for optimal performance.
blockMultiQueue : false上記のYAMLをOpenStackControlPlane.YAMLというファイルに書き込む場合、このコマンドを介してOpenStackControlPlaneを作成できます。
oc create -f openstackcontrolplane.yaml注VMSET（VMロール）内のVMは、PODアフィニティルール（PrefredDuringsChedulingIgnOordExecution）を使用して、利用可能なワーカーノード全体に分布します。これにより、他のリソースが利用できない場合、役割の複数のVMが同じワーカーノードで終わる可能性があります（たとえば、更新中にワーカーの再起動）。メンテナンス/再起動後にノードが表示される場合、自動ライブ移行は発生しません。次のスケジューリングリクエストでは、VMが再び再配置されます。
OpenStackBareMetalsetを定義して、OSP計算ホストを拡大します。 OpenStackBareMetalリソースを使用して、リソースの計算を定義および拡張し、オプションで使用して、他のタイプのトリプルロールのbaremetalホストを定義およびスケーリングすることができます。以下の例は、作成される単一の計算ホストを定義します。
注：Rhel-Guest-ImageがBaseとして使用されてOpenStackBareMetalsetコンピューテノードを展開する場合は、Net.ifNames = 0 Kernelパラメーターを画像から削除して、BioSDEVネットワークインターフェイスの名前を付けるようにしてください。これは次のように行うことができます。
dnf install -y libguestfs-tools-c
virt-customize -a bms-image.qcow2 --run-command ' sed -i -e "s/^(kernelopts=.*)net.ifnames=0 (.*)/12/" /boot/grub2/grubenv ' apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackBaremetalSet
metadata :
name : compute
namespace : openstack
spec :
# How many nodes to provision
count : 1
# The image to install on the provisioned nodes. NOTE: needs to be accessible on the OpenShift Metal3 provisioning network.
baseImageUrl : http://host/images/rhel-image-8.4.x86_64.qcow2
# NOTE: these are automatically created via the OpenStackControlplane CR above
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
- internalapi
- tenant
- storage
roleName : Compute
passwordSecret : userpassword上記のYAMLをcompute.yamlというファイルに書き込む場合、このコマンドを介してOpenStackBareMetalsetを作成できます。
oc create -f compute.yamlノード登録（オーバークラウドシステムを必要なチャネルに登録）
上記のリソースが展開（ComputeおよびControlPlane）が完了するのを待ちます。リソースの展開が終了したら、ノード登録を続行します。
5.9で説明されている手順を使用します。 Ansibleベースの登録を手動で実行することはそうします。
注：ベース画像の選択に関係なく、手動登録を使用することをお勧めします。このアプローチの代替として、base deploymentイメージとしてオーバークラウドフルを使用している場合、Tht RHSM.yaml環境ロール/ファイルを介して自動RHSM登録を使用できます。
oc rsh openstackclient
bash
cd /home/cloud-admin
< create the ansible playbook for the overcloud nodes - e.g. rhsm.yaml >
# register the overcloud nodes to required repositories
ansible-playbook -i /home/cloud-admin/ctlplane-ansible-inventory ./rhsm.yaml（オプション）ロールファイルの作成a）OpenStackClient PODを使用して、カスタムロールファイルを生成します
oc rsh openstackclient
unset OS_CLOUD
cd /home/cloud-admin/
openstack overcloud roles generate Controller ComputeHCI > roles_data.yaml
exitb）OpenStackClientポッドからカスタムロールファイルをコピーします
oc cp openstackclient:/home/cloud-admin/roles_data.yaml roles_data.yaml tarballConfigMap configMapを更新して、 roles_data.yamlファイルをTarballに追加し、ConfigMapを更新します。
注：file nameとしてroles_data.yamlを使用してください。
OpenStackConfigGeneratorを定義して、OSPクラスターの展開用のAnsible Playbookを生成します。
apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackConfigGenerator
metadata :
name : default
namespace : openstack
spec :
enableFencing : False
imageURL : quay.io/openstack-k8s-operators/rhosp16-openstack-tripleoclient:16.2_20210713.1
gitSecret : git-secret
heatEnvConfigMap : heat-env-config
tarballConfigMap : tripleo-tarball-config
# (optional) for debugging it is possible to set the interactive mode.
# In this mode the playbooks won't get rendered automatically. Just the environment to start the rendering gets created
# interactive: true
# (optional) provide custom registry or specific container versions via the ephemeralHeatSettings
# ephemeralHeatSettings:
# heatAPIImageURL: quay.io/tripleotraincentos8/centos-binary-heat-api:current-tripleo
# heatEngineImageURL: quay.io/tripleotraincentos8/centos-binary-heat-engine:current-tripleo
# mariadbImageURL: quay.io/tripleotraincentos8/centos-binary-mariadb:current-tripleo
# rabbitImageURL: quay.io/tripleotraincentos8/centos-binary-rabbitmq:current-tripleo上記のYAMLをGenerator.YAMLというファイルに書き込む場合、このコマンドを介してOpenStackConfigGeneratorを作成できます。
oc create -f generator.yaml上記で作成されたOsconFiggeneratorは、OSP展開のconfigMapsをスケーリングまたは変更するたびにプレイブックを自動的に生成します。これらのプレイブックを生成するには数分かかります。 OsconFiggeneratorのステータス条件を監視して、終了することができます。
最新のOsconfigversion（Ansible Playbooks）を入手してください。次のステップで使用するために、最新のOsconfigversionのハッシュ/ダイジェストを選択します。
oc get -n openstack --sort-by {.metadata.creationTimestamp} osconfigversions -o json注：Osconfigversionオブジェクトには、Ansible Playbookバージョン間の変更を簡単に比較するために使用できる「Git Diff」属性もあります。
osdeployを作成する（Ansible Playbooksを実行）
apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackDeploy
metadata :
name : default
spec :
configVersion : n5fch96h548h75hf4hbdhb8hfdh676h57bh96h5c5h59hf4h88h...
configGenerator : default上記のyamlをdeploy.yamlというファイルに書き込む場合、このコマンドを介してOpenStackDeployを作成できます。
oc create -f deploy.yaml展開が実行されると、Kubernetesのジョブが作成され、Ansible Playbooksが実行されます。このジョブ/ポッドのログをテールして、Ansible Playbookが実行されるのを見ることができます。さらに、「OpenStackClient」ポッドにログインして、/home/cloud-admin/work //ディレクトリに移動することにより、実行されたAnsible Playbooksに手動でアクセスできます。そこには、実行中の展開用のAnsible.logファイルとともに、Ansible Playbooksがあります。
コンピューティングノードもCEPH OSDノードとして機能するTripleoのハイパーコンバージドインフラストラクチャを展開することができます。 Tripleoを介してCEPHをインストールするワークフローは次のとおりです。
openStackClient openStackClientImageURLには、 quay.io/openstack-k8s-operators/rhosp16-openstack-tripleoclient:16.2_20210521.1 /openstack-k8s-operators/rhosp16-openstack-tripleoclient:16.2_20210521.1以降を使用してください。
OSDとして使用する追加ディスクを備えた計算ノードを使用し、デフォルトのComputeネットワークとIsHCIパラメーターをtrueに設定したstoragemgmtネットワークを備えたcomputehciロールのbaremetalsetを作成します。
注：Rhel-Guest-ImageがBaseとして使用されてOpenStackBareMetalset Computeノードを展開する場合は、Net.ifNames = 0 Kernelパラメーターを削除して、BioSDEVネットワークインターフェイスネーミングを持つように画像を形成してください。これは次のように行うことができます。
dnf install -y libguestfs-tools-c
virt-customize -a bms-image.qcow2 --run-command ' sed -i -e "s/^(kernelopts=.*)net.ifnames=0 (.*)/12/" /boot/grub2/grubenv ' apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackBaremetalSet
metadata :
name : computehci
namespace : openstack
spec :
# How many nodes to provision
replicas : 2
# The image to install on the provisioned nodes
baseImageUrl : http://host/images/rhel-image-8.4.x86_64.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
- internalapi
- tenant
- storage
- storagemgmt
roleName : ComputeHCI
passwordSecret : userpassword Deploying OpenStack once you have the OSP Director Operator installedセクションで説明されているように役割ファイルを作成します/usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yamlからCEPH関連の展開パラメーターを追加しますstorage-backend.yaml resource_registry :
OS::TripleO::Services::CephMgr : deployment/ceph-ansible/ceph-mgr.yaml
OS::TripleO::Services::CephMon : deployment/ceph-ansible/ceph-mon.yaml
OS::TripleO::Services::CephOSD : deployment/ceph-ansible/ceph-osd.yaml
OS::TripleO::Services::CephClient : deployment/ceph-ansible/ceph-client.yaml
parameter_defaults :
# needed for now because of the repo used to create tripleo-deploy image
CephAnsibleRepo : " rhelosp-ceph-4-tools "
CephAnsiblePlaybookVerbosity : 3
CinderEnableIscsiBackend : false
CinderEnableRbdBackend : true
CinderBackupBackend : ceph
CinderEnableNfsBackend : false
NovaEnableRbdBackend : true
GlanceBackend : rbd
CinderRbdPoolName : " volumes "
NovaRbdPoolName : " vms "
GlanceRbdPoolName : " images "
CephPoolDefaultPgNum : 32
CephPoolDefaultSize : 2
CephAnsibleDisksConfig :
devices :
- ' /dev/sdb '
- ' /dev/sdc '
- ' /dev/sdd '
osd_scenario : lvm
osd_objectstore : bluestore
CephAnsibleExtraConfig :
is_hci : true
CephConfigOverrides :
rgw_swift_enforce_content_length : true
rgw_swift_versioning_enabled : true環境の上記のテンプレート/例をカスタマイズしたら、 Deploying OpenStack once you have the OSP Director Operator installedで説明したようなConfigMapsを作成/更新します
Deploying OpenStack once you have the OSP Director Operator installed 。注：osconfiggenerator imageURLには、 quay.io/openstack-k8s-operators/rhosp16-openstack-tripleoclient:16.2_20210521.1 /openstack-k8s-operators/rhosp16-openstack-tripleoclient:16.2_202105210521052105210521.1を使用してください。
OpenStackConfigGeneratorがプレイブックのレンダリングジョブを完了するのを待ちます。
最新のOpenStackConfigversionのハッシュ/ダイジェストを取得します。
指定されたOpenStackConfigversion用のOpenStackDeployを作成します。これにより、Ansible Playbooksが展開されます。
Baremetal Computeホストを削除するには、次の手順が必要です。
計算ノードが削除された場合、オーバークラウドの発信ノード上の計算サービスを無効にして、ノードが新しいインスタンスのスケジュールを防ぐのを防ぎます
openstack compute service list
openstack compute service set < hostname > nova-compute --disableBMHリソースの注釈
oc annotate -n openshift-machine-api bmh/openshift-worker-3 osp-director.openstack.org/delete-host=true --overwrite注釈ステータスは、 annotatedForDeletionパラメーターを使用して、OsbareMetalset/OSVMSTに反映されています。
oc get osbms computehci -o json | jq .status
{
" baremetalHosts " : {
" computehci-0 " : {
" annotatedForDeletion " : true,
" ctlplaneIP " : " 192.168.25.105/24 " ,
" hostRef " : " openshift-worker-3 " ,
" hostname " : " computehci-0 " ,
" networkDataSecretName " : " computehci-cloudinit-networkdata-openshift-worker-3 " ,
" provisioningState " : " provisioned " ,
" userDataSecretName " : " computehci-cloudinit-userdata-openshift-worker-3 "
},
" computehci-1 " : {
" annotatedForDeletion " : false,
" ctlplaneIP " : " 192.168.25.106/24 " ,
" hostRef " : " openshift-worker-4 " ,
" hostname " : " computehci-1 " ,
" networkDataSecretName " : " computehci-cloudinit-networkdata-openshift-worker-4 " ,
" provisioningState " : " provisioned " ,
" userDataSecretName " : " computehci-cloudinit-userdata-openshift-worker-4 "
}
},
" provisioningStatus " : {
" readyCount " : 2,
" reason " : " All requested BaremetalHosts have been provisioned " ,
" state " : " provisioned "
}
}オスバレメタルセットのリソース数を減らすと、リソースの削除を処理するためにコレンズポンディングコントローラーがトリガーされます
oc patch osbms computehci --type=merge --patch ' {"spec":{"count":1}} '結果として：
oc get osnet ctlplane -o json | jq .status.roleReservations.ComputeHCI
{
" addToPredictableIPs " : true,
" reservations " : [
{
" deleted " : true,
" hostname " : " computehci-0 " ,
" ip " : " 192.168.25.105 " ,
" vip " : false
},
{
" deleted " : false,
" hostname " : " computehci-1 " ,
" ip " : " 192.168.25.106 " ,
" vip " : false
}
]
}これにより、次の動作が生じます
現在、計算ノードが削除された場合、OpenStackコントロールプレーンにいくつかの残りのエントリが登録されており、自動的にクリーンアップされていません。それらをきれいにするには、次の手順を実行します。
openstack compute service list
openstack compute service delete < service-id >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 VMを削除するには、次の手順が必要です。
VMが削除前に無効にする必要があるOSPサービスをホストしている場合は、そうしてください。
VMリソースの注釈
oc annotate -n openstack vm/controller-1 osp-director.openstack.org/delete-host=true --overwriteOpenStackControlPlane CRのVirtualMachinerolesのリソースの削減。リソースの削除を処理するためのコレンズポンディングコントローラー
oc patch osctlplane overcloud --type=merge --patch ' {"spec":{"virtualMachineRoles":{"<RoleName>":{"roleCount":2}}}} '結果として：
これにより、次の動作が生じます
VMが削除する必要があるOSPサービスをホストした場合、対応するOpenStackコマンドを使用してサービスを削除します。
OverCloud Leafネットワークを構成して、Tripleoのルーティングネットワーク（スパイン/リーフネットワーク）アーキテクチャを展開することができます。サブネットパラメーターを使用して、ベースネットワークを使用して追加のリーフサブネットを定義します。
現在の制限は、Metal3のプロビジョニングネットワークが1つしかないことです。
複数のサブネットを使用してオーバークラウドをインストールするワークフローは次のとおりです。
OpenStackNetConfigカスタムリソースを定義し、オーバークラウドネットワークのすべてのサブネットを指定します。オペレーターは、使用済みのOSPリリースのためにTripleo Network_data.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-osp
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上記のYAMLをNetworkConfig.yamlというファイルに書き込む場合、このコマンドを介してOpenStackNetConfigを作成できます。
oc create -n openstack -f networkconfig.yaml...
# ##############################################################################
# Role: ComputeLeaf1 #
# ##############################################################################
- name : ComputeLeaf1
description : |
Basic ComputeLeaf1 Node role
# Create external Neutron bridge (unset if using ML2/OVS without DVR)
tags :
- 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 :
- external_bridge
networks :
InternalApi :
subnet : internal_api_leaf2
Tenant :
subnet : tenant_leaf2
Storage :
subnet : storage_leaf2
HostnameFormatDefault : ' %stackname%-novacompute-leaf2-%index% '
... tarballConfigMap configMapを更新して、 roles_data.yamlファイルをTarballに追加し、ConfigMapを更新します。
注：file nameとしてroles_data.yamlを使用してください。
OSP 16.2 Tripleo Nicテンプレートには、デフォルトごとにインターフェーサーパラメーターが含まれています。環境/ネットワーク環境でレンダリングされたルートパラメーター。名前付きルートのYAMLは、通常、中性子ネットワークHOST_ROUTESプロパティに設定され、Interfaceroutesパラメーターの役割に追加されます。中性子がないため、必要に応じて{{network.name}}ルートをNICテンプレートに追加し、2つのリストを連結する必要があります。
parameters:
...
{{ $net.Name }}Routes:
default: []
description: >
Routes for the storage network traffic.
JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}]
Unless the default is changed, the parameter is automatically resolved
from the subnet host_routes attribute.
type: json
...
- type: interface
...
routes:
list_concat_unique:
- get_param: {{ $net.Name }}Routes
- get_param: {{ $net.Name }}InterfaceRoutes
ルートサブネット情報は、Ansible Playbookをレンダリングするスクリプトで使用されるTripleo環境ファイルenvironments/network-environment.yamlに自動化されます。したがって、NICテンプレートでは、routes_ <subnet_name>を使用して、storageroutes_storage_leaf1を使用して、ホストの正しいルーティングを設定します。
computeleaf1コンピューティングロールの場合、NICテンプレートを変更する必要があります。
...
StorageRoutes_storage_leaf1 :
default : []
description : >
Routes for the storage network traffic.
JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}]
Unless the default is changed, the parameter is automatically resolved
from the subnet host_routes attribute.
type : json
...
InternalApiRoutes_internal_api_leaf1 :
default : []
description : >
Routes for the internal_api network traffic.
JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}]
Unless the default is changed, the parameter is automatically resolved
from the subnet host_routes attribute.
type : json
...
TenantRoutes_tenant_leaf1 :
default : []
description : >
Routes for the internal_api network traffic.
JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}]
Unless the default is changed, the parameter is automatically resolved
from the subnet host_routes attribute.
type : json
...
get_param : StorageIpSubnet
routes :
list_concat_unique :
- get_param : StorageRoutes_storage_leaf1
- type : vlan
...
get_param : InternalApiIpSubnet
routes :
list_concat_unique :
- get_param : InternalApiRoutes_internal_api_leaf1
...
get_param : TenantIpSubnet
routes :
list_concat_unique :
- get_param : TenantRoutes_tenant_leaf1
- type : ovs_bridge
... tarballConfigMap ConfigMapを更新して、NICテンプレートroles_data.yamlファイルをTarballに追加し、ConfigMapを更新します。
注：file nameとしてroles_data.yamlを使用してください。
これまでのところ、OSP16.2のみが複数のサブネット展開でテストされ、OSP17.0シングルサブネットと互換性がありました。
TBD
新しいノードロールのために、新しい作成されたNICテンプレートを環境ファイルにresource_registryに追加してください。
resource_registry :
OS::TripleO::Compute::Net::SoftwareConfig : net-config-two-nic-vlan-compute.yaml
OS::TripleO::ComputeLeaf1::Net::SoftwareConfig : net-config-two-nic-vlan-compute_leaf1.yaml
OS::TripleO::ComputeLeaf2::Net::SoftwareConfig : net-config-two-nic-vlan-compute_leaf2.yaml この時点で、オーバークラウドをプロビジョニングできます。
apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackControlPlane
metadata :
name : overcloud
namespace : openstack
spec :
gitSecret : git-secret
openStackClientImageURL : registry.redhat.io/rhosp-rhel8/openstack-tripleoclient:16.2
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 : 40
baseImageVolumeName : controller-base-img
storageClass : host-nfs-storageclass
storageAccessMode : ReadWriteMany
storageVolumeMode : Filesystem 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://192.168.111.1/images/rhel-guest-image-8.4-1168.x86_64.qcow2
provisionServerName : openstack
# 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 apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackBaremetalSet
metadata :
name : computeleaf2
namespace : openstack
spec :
# How many nodes to provision
count : 1
# The image to install on the provisioned nodes
baseImageUrl : http://192.168.111.1/images/rhel-guest-image-8.4-1168.x86_64.qcow2
provisionServerName : openstack
# 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_leaf2
- external
- tenant_leaf2
- storage_leaf2
roleName : ComputeLeaf2
passwordSecret : userpasswordOPPLSTACKCONFIGGENERATORを定義して、OSP Cluster deploymentのAnsible Playbooksを生成してDeploying OpenStack once you have the OSP Director Operator installed 。
実行中に説明されているように、 Run the software deployment 、適用して、オーバークラウドノードを必要なリポジトリに登録し、OpenStackClient POD内からソフウェア展開を実行します。
OSP-Dオペレーターは、現在のCR、ConfigMap、Secret Configurationsのバックアップを作成および復元するAPIを提供します。このAPIは2つのCRDで構成されています。
OpenStackBackupRequestOpenStackBackup OpenStackBackupRequest CRDは、バックアップの作成または復元を開始するために使用されますが、 OpenStackBackup CRDは、オペレーターに属するCR、ConfigMap、およびSecretデータを実際に保存するために使用されます。これにより、いくつかの利点が可能になります。
OpenStackBackup CRとして表現することにより、ユーザーはオペレーターの構成の各ピースを手動でエクスポート/インポートする必要がありませんOpenStackBackupの作成を開始するには、SPECにsaveようにmodeを設定してOpenStackBackupRequestを作成します。例えば： apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackBackupRequest
metadata :
name : openstackbackupsave
namespace : openstack
spec :
mode : save
additionalConfigMaps : []
additionalSecrets : []仕様フィールドは次のとおりです。
mode: saveこれがバックアップを作成するリクエストであることを示します。additionalConfigMapsとadditionalSecretsリストを使用して、オペレーターが気づかない補足的な構成と秘密を含めることができます（つまり、特定の目的のために手動で作成されたsecretと秘密）。OpenStackControlPlane 、 OpenStackBaremetalSetなど）に関連付けられたすべてのconfigMapsとsecretを含めることを試みます。OpenStackBackupRequestが作成されたら、そのステータスを監視してください。 oc get -n openstack osbackuprequest openstackbackupsaveこのようなものが表示されるはずです：
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackupsave save Quiescing Quiescing状態は、オペレーターがすべてのOSP-DオペレーターCRのプロビジョニング状態が「完成した」同等物に到達するのを待っていることを示しています。これに必要な時間は、OSP-DオペレーターCRSの量と現在のプロビジョニング状態の偶然に基づいて異なります。注：既存のCRSのエラーや「待機」状態のために、オペレーターが完全にQuiesceしない可能性があります。どのCRDS/CRがクイエンスを防止しているかを確認するには、オペレーターログを調査します。例えば：
oc logs < OSP-D 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] OpenStackBackupRequest Error状態に入る場合、その完全な内容を調べて、遭遇したエラーを確認します（ oc get -n openstack openstackbackuprequest <name> -o yaml ）。
OpenStackBackupRequestが、現在のOSP-Dオペレーター構成を表すOpenStackBackup作成および保存することで表彰されると、 Saved Stateに入ります。例えば： oc get -n openstack osbackuprequest
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackupsave save Saved 2022-01-11T19:12:58Z関連するOpenStackBackupも作成されます。例えば：
oc get -n openstack osbackup
NAME AGE
openstackbackupsave-1641928378 6m7sOpenStackBackupの修復を開始するには、SPECでrestoreように設定されたmodeを使用してOpenStackBackupRequestを作成します。例えば： apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackBackupRequest
metadata :
name : openstackbackuprestore
namespace : openstack
spec :
mode : restore
restoreSource : openstackbackupsave-1641928378仕様フィールドは次のとおりです。
mode: restoreこれが既存のOpenStackBackup復元するリクエストであることを示します。restoreSourceどのOpenStackBackup復元するかを示します。 mode restoreように設定されている場合、OSP-Dオペレーターは、 restoreSource OpenStackBackupの内容を取得し、名前空間内に現在存在する既存のCRS、ConfigMaps、およびSecretに対して適用しようとします。したがって、名前空間の既存のOSP-DオペレーターリソースをOpenStackBackupの名前と同じ名前で上書きし、名前空間に現在見つからない人々のための新しいリソースを作成します。必要に応じて、 mode cleanRestoreに設定して、復元を試みる前に名前空間内の既存のOSP-Dオペレーターリソースを完全に拭くことができます。これにより、 OpenStackBackup内のすべてのリソースが完全に作成されます。
OpenStackBackupRequestが作成されたら、そのステータスを監視してください。 oc get -n openstack osbackuprequest openstackbackuprestoreこのようなものは、 OpenStackBackupのすべてのリソースがクラスターに対して適用されていることを示しているように見えるはずです。
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackuprestore restore openstackbackupsave-1641928378 Loading その後、すべてのリソースがロードされると、オペレーターはすべてのリソースの提供を試みるために調整を開始します。
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackuprestore restore openstackbackupsave-1641928378 Reconciling OpenStackBackupRequest Error状態に入る場合、その完全な内容を調べて、遭遇したエラーを確認します（ oc get -n openstack openstackbackuprequest <name> -o yaml ）。
OpenStackBackupRequest OpenStackBackup完全に復元することで表彰されたとき、 Restored状態に入ります。例えば： oc get -n openstack osbackuprequest
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackuprestore restore openstackbackupsave-1641928378 Restored 2022-01-12T13:48:57Zこの時点で、選択したOpenStackBackupに含まれるすべてのリソースを復元し、完全にプロビジョニングする必要があります。
OSPディレクターのオペレーターは、各osdePloyリソースが実行された後、ConfigMapを自動的に作成します。このConfigMapは、OsDeployリソース名にちなんで命名され、Tripleo-Exports-が付いています。たとえば、Tripleo-Exports-Defaultは、「デフォルト」OsdePloyリソースのConfigMapの名前です。各configmapには2つのyamlファイルが含まれています。
| ファイル名 | 説明 | Tripleoコマンドに相当します |
|---|---|---|
| ctlplane-export.yaml | DCNの複数のスタックで使用されます | オーバークラウドエクスポート |
| ctlplane-export-filtered.yaml | セルの「コントローラー」スタックを使用した複数のスタックに使用されます | オーバークラウドセルのエクスポート |
以下のコマンドを使用して、ConfigMapからYAMLファイルを抽出します。抽出すると、YAMLファイルをOsconFiggeneratorリソースのカスタムヒートパラメーターに追加できます。
oc extract cm/tripleo-exports-default注：OSPディレクターのオペレーターは、CEPHスタックの輸出をまだ生成していません。
必要に応じて、OpenStackControlPlaneを介して構成されたOpenStackVMSetのCPU/RAMを変更することが可能です。ワークフローは次のとおりです。
たとえば、コントローラーVirtualMachineroleを変更して、8つのコアと22GBのRAMを持つようにします。
oc patch -n openstack osctlplane overcloud --type= ' json ' -p= ' [{"op": "add", "path": "/spec/virtualMachineRoles/controller/cores", "value": 8 }] '
oc patch -n openstack osctlplane overcloud --type= ' json ' -p= ' [{"op": "add", "path": "/spec/virtualMachineRoles/controller/memory", "value": 22 }] '
oc get osvmset
NAME CORES RAM DESIRED READY STATUS REASON
controller 8 22 1 1 Provisioned All requested VirtualMachines have been provisionedvirtctl start <VM>使用してVMを元に戻すことです。 OSP更新プロセスドキュメントを参照してください
