osp director operator
v1.2.3
L'opérateur OSP Director crée un ensemble de définitions de ressources personnalisées en plus d'OpenShift pour gérer les ressources normalement créées par le sous-cloud du Tripleo. Ces CRD sont divisés en deux types pour l'approvisionnement matériel et la configuration des logiciels.
L'opérateur OSP Director est installé et géré via le OLM Operator Lifecycle Manager. OLM est installé automatiquement avec votre installation OpenShift. Pour obtenir le dernier instantané de l'opérateur OSP Director, vous devez créer le CatalogSource, Operatorgroup et abonnement appropriés pour conduire l'installation avec OLM:
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 : alphaNous avons un script pour automatiser l'installation ici avec OLM pour une balise spécifique: le script pour automatiser l'installation
Remarque : À un moment donné dans le futur, nous pouvons nous intégrer à OperatorHub afin que l'opérateur OSP Director soit disponible automatiquement dans les sources de catalogue OLM par défaut d'OCP Installations.
Créez un volume de données RHEL de base avant de déployer OpenStack. Ceci sera utilisé par les machines virtuelles du contrôleur qui sont provisionnées via une virtualisation OpenShift. L'approche pour le faire est la suivante:
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 ci-dessus, choisissez une que vous souhaitez utiliser à partir de celles indiquées dans: oc get storageclass
Définissez votre ressource personnalisée OpenStackNetConfig. Au moins un réseau est requis pour le CTLPlane. Facultativement, vous pouvez définir plusieurs réseaux dans le CR pour être utilisés avec l'architecture d'isolement de réseau de Tripleo. En plus de la définition du réseau, OpenStackNet comprend des informations utilisées pour définir la stratégie de configuration du réseau utilisée pour attacher toutes les machines virtuelles à ce réseau via une virtualisation OpenShift. Ce qui suit est un exemple d'un simple réseau IPv4 CTLPlane qui utilise Linux Bridge pour sa configuration d'hôte.
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:bbSi vous écrivez le YAML ci-dessus dans un fichier appelé NetworkConfig.yaml, vous pouvez créer l'OpenStackNetConfig via cette commande:
oc create -n openstack -f networkconfig.yamlPour utiliser l'isolement réseau à l'aide de VLAN, ajoutez l'ID VLAN à la spécification de la définition du réseau
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-ospLorsque vous utilisez VLAN pour l'isolement du réseau avec Linux-Bridge
Remarque : Pour utiliser les trames jumbo pour un pont, créez une configuration pour le périphérique pour configurer le Correnct 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 Créer des configmaps qui définissent tous les environnements de chaleur personnalisés, les modèles de chaleur et le fichier de rôles personnalisés (le nom doit être roles_data.yaml ) utilisé pour la configuration du réseau Tripleo. Tous les fichiers d'environnement de chaleur définis par l'administrateur peuvent être fournis dans la configmap et seront utilisés comme convention dans les étapes ultérieures utilisées pour créer la pile de chaleur pour le déploiement d'overcoud. En tant que convention, chaque installation OSP Director utilisera 2 configmaps nommés heat-env-config et tripleo-tarball-config pour fournir ces informations. La configmap heat-env-config contient tous les fichiers d'environnement de déploiement où chaque fichier est ajouté en tant -e file.yaml à la commande openstack stack create . Un bon exemple est:
Une "carte de configuration de tarball" peut être utilisée pour fournir des boulets (binaires) qui sont extraits dans les Tripleo-Heat-Templates lorsque les manuels de jeu sont générés. Chaque tarball doit contenir un répertoire de fichiers relative à la racine d'un répertoire THT. Vous voudrez stocker des choses comme les exemples suivants dans une carte de configuration contenant des tarball personnalisés:
Fichiers net-config.
Environnement net-config
Remarque : les fichiers net-config pour les machines virtuels sont créés par l'opérateur, mais peuvent être écrasés à l'aide de la "carte de configuration de tarball". Pour écraser un net-config pré-renvoyé, utilisez le nom de fichier <role lowercase>-nic-template.yaml pour OSP16.2 ou <role lowercase>-nic-template.j2 pour OSP17. Remarque : les noms d'interface réseau pour les machines virtuelles créées par le contrôleur OpenStackVMSET sont commandées par ordre alphabétique par les noms de réseau attribués au rôle de machine virtuelle. Une exception est l'interface réseau default du POD VM qui sera toujours la première interface. La section Inteface résultante de la définition de la machine virtuelle ressemblera à ceci:
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 : tenantAvec cela, l'interface CTLPlane est NIC2, NIC3 externe, et ainsi de suite.
Remarque : Le trafic FIP ne passe pas à un réseau de locataires VLAN avec ML2 / OVN et DVR. DVR est activé par défaut. Si vous avez besoin de réseaux de locataires VLAN avec OVN, vous pouvez désactiver le DVR. Pour désactiver le DVR, incluez les lignes suivantes dans un fichier environnement:
parameter_defaults :
NeutronEnableDVR : falseLa prise en charge de "Distributed VLAN Traffic in OVN" est en cours de suivi dans Gérer les adresses MAC pour "Ajouter un support dans Tripleo pour le trafic VLAN distribué dans OVN" (https://bugs.launchpad.net/tripleo/+bug/1881593)
[Git Repo Config Map] Cette configmap contient la touche SSH et l'URL pour le repo git utilisé pour stocker les livres de jeu générés (ci-dessous)
Une fois que vous avez personnalisé le modèle / exemples / exemples ci-dessus pour votre environnement, vous pouvez créer des configmaps pour les configmaps «Tripleo-Tarball-Config» (Tarball) en utilisant ces fichiers contenant chaque type de configmap respectif (Tarball) en utilisant ces exemples de commandes sur les fichiers contenant chaque type de configmap respectif (un répertoire pour chaque type de configmap):
# 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@...) >
(Facultatif) Créez un secret pour votre OpenStackControlPlane. Ce secret fournira le mot de passe par défaut de votre machine virtuelle et des hôtes de baremetal. Si aucun secret n'est prévu, vous ne pourrez vous connecter qu'avec des clés SSH définies dans le secret OSP-Controlplane-Ssh-Keys.
apiVersion : v1
kind : Secret
metadata :
name : userpassword
namespace : openstack
data :
# 12345678
NodeRootPassword : MTIzNDU2Nzg=Si vous écrivez le YAML ci-dessus dans un fichier appelé ctlplane-seret.yaml, vous pouvez créer le secret via cette commande:
oc create -n openstack -f ctlplane-secret.yamlDéfinissez votre ressource personnalisée OpenStackControlPlane. La ressource personnalisée OpenStackControlPlane fournit un endroit central pour créer et mettre à l'échelle les machines virtuelles utilisées pour les contrôleurs OSP ainsi que les VMSET supplémentaires pour votre déploiement. Au moins 1 machine virtuelle de contrôleur est requise pour une installation de démonstration de base et des lignes directrices OSP à haute disponibilité 3 machines virtuelles de contrôleur sont recommandées.
Remarque : Si l'image RHEL-Guest est utilisée comme base pour déployer les machines virtuelles OpenStackControlPlane, assurez-vous de supprimer le paramètre Net.IfNames = 0 du noyau de l'image pour que le nom de l'interface du réseau biosdev. Cela peut être fait comme:
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 : falseSi vous écrivez le YAML ci-dessus dans un fichier appelé OpenStackControlPlane.yaml, vous pouvez créer l'OpenStackControlPlane via cette commande:
oc create -f openstackcontrolplane.yamlRemarque les machines virtuelles dans le même VMSET (rôle VM) sont distribuées dans les nœuds de travail disponibles en utilisant une règle anti-affinité POD (préférée DuringSCheDuLingInGoredUringExecution). Avec cela, il est toujours possible que plusieurs machines virtuelles d'un rôle se retrouvent sur le même nœud de travailleur si aucune autre ressource n'est disponible (par exemple, redémarrer les travailleurs pendant la mise à jour). Il n'y a pas de migration en direct automatique, si un nœud apparaît après la maintenance / redémarrage. Lors de la prochaine demande de planification, la machine virtuelle est à nouveau déplacée.
Définissez un OpenStackBareMetalseT pour étendre les hôtes OSP Calcul. La ressource OpenStackBaremetal peut être utilisée pour définir et mettre à l'échelle des ressources de calcul et être éventuellement utilisées pour définir et développer des hôtes de baremetal pour d'autres types de rôles Tripleo. L'exemple ci-dessous définit un seul hôte de calcul à créer.
Remarque : Si l'image RHEL-Guest-Image est utilisée comme base pour déployer les nœuds de calcul OpenStackBareMetalSet, assurez-vous de supprimer le paramètre Net.IfNames = 0 du noyau de l'image pour que le nom de l'interface du réseau Biosdev. Cela peut être fait comme:
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 : userpasswordSi vous écrivez le YAML ci-dessus dans un fichier appelé calcul.yaml, vous pouvez créer l'OpenStackBareMetalset via cette commande:
oc create -f compute.yamlEnregistrement du nœud (enregistrez les systèmes Overcloud aux canaux requis)
Attendez que la ressource ci-dessus termine le déploiement (calcul et plan de contrôle). Une fois les ressources terminées par le déploiement, procédez par l'enregistrement des nœuds.
Utilisez la procédure comme décrit dans 5.9. L'exécution de l'enregistrement basé sur ANSIBLE le fait manuellement.
Remarque: Nous recommandons d'utiliser l'enregistrement manuel tel qu'il fonctionne quel que soit le choix de l'image de base. Si vous utilisez Overcloud-Full comme image de déploiement de base, l'enregistrement Automatique RHSM pourrait être utilisé via le rôle / fichier d'environnement RHSM.YAML comme alternative à cette approche.
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(Facultatif) Créer des rôles Fichier a) Utilisez le pod OpenStackClient pour générer un fichier de rôles personnalisés
oc rsh openstackclient
unset OS_CLOUD
cd /home/cloud-admin/
openstack overcloud roles generate Controller ComputeHCI > roles_data.yaml
exitb) Copiez le fichier des rôles personnalisés du pod OpenStackClient
oc cp openstackclient:/home/cloud-admin/roles_data.yaml roles_data.yaml Mettez à jour le tarballConfigMap ConfigMap pour ajouter le fichier roles_data.yaml au Tarball et mettez à jour la configmap.
Remarque : assurez-vous d'utiliser roles_data.yaml comme nom de fichier.
Définissez un OpenStackConfigenerator pour générer des lecteurs de playons ANSIBL pour le déploiement du cluster OSP.
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-tripleoSi vous écrivez le YAML ci-dessus dans un fichier appelé générateur Generator.yaml, vous pouvez créer l'OpenStackConfigenerator via cette commande:
oc create -f generator.yamlL'OsconFiggenerator créé ci-dessus générera automatiquement PlayBooks chaque fois que vous réduisez ou modifiez les configmaps pour votre déploiement OSP. La génération de ces manuels prend plusieurs minutes. Vous pouvez surveiller la condition d'état de l'Osconfigenerator pour qu'il se termine.
Obtenez le dernier Osconfigversion (ANSIBL PlayBooks). Sélectionnez le hachage / digest de la dernière Osconfigversion pour une utilisation à l'étape suivante.
oc get -n openstack --sort-by {.metadata.creationTimestamp} osconfigversions -o jsonRemarque: Les objets Osconfigversion ont également un attribut «git diff» qui peut être utilisé pour comparer facilement les changements entre les versions PlayBook ANSIBL.
Créer un OSDeploy (exécute ANSIBLE PlayBooks)
apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackDeploy
metadata :
name : default
spec :
configVersion : n5fch96h548h75hf4hbdhb8hfdh676h57bh96h5c5h59hf4h88h...
configGenerator : defaultSi vous écrivez le YAML ci-dessus dans un fichier appelé Deploy.yaml, vous pouvez créer le OpenStackDeploy via cette commande:
oc create -f deploy.yamlAu fur et à mesure que le déploiement s'exécute, il créera un travail Kubernetes pour exécuter les PlayBooks Ansible. Vous pouvez rédiger les journaux de ce travail / pod pour regarder les playbooks ANSIBL. De plus, vous pouvez accéder manuellement aux manuels Anible exécutés en vous connectant dans le pod 'OpenStackClient', en entrant dans le répertoire / home / cloud-admin / work //. Là, vous trouverez les PlayBooks ANSIBL avec le fichier ANSIBLE.log pour le déploiement en cours d'exécution.
Il est possible de déployer l'infrastructure hyperconvergée de Tripleo où les nœuds de calcul agissent également comme des nœuds CEPH OSD. Le flux de travail pour installer Ceph via Tripleo serait:
Assurez-vous d'utiliser quay.io/openstack-k8s-operators/rhosp16-openstack-tripleoclient:16.2_20210521.1 ou ultérieure pour l'OpenStackClient openStackClientImageURL .
Ayez des nœuds de calcul avec des disques supplémentaires à utiliser comme OSD et créez un BareMetalSet pour le rôle de calculhci qui a le réseau StorageMGMT en plus des réseaux de calcul par défaut et le paramètre IsHCI défini sur true.
Remarque : Si l'image RHEL-Guest-Image est utilisée comme base pour déployer les nœuds de calcul OpenStackBareMetalSet, assurez-vous de supprimer le paramètre Net.IfNames = 0 du noyau, former l'image pour que le nom de l'interface du réseau Biosdev. Cela peut être fait comme:
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 qui comprend le rôle de calculhci/usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml et toute autre personnalisation à la configmap personnalisée Tripleo Deploy, par exemple 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 Une fois que vous avez personnalisé le modèle / exemples / exemples ci-dessus pour votre environnement, créez / mise à jour des configmaps comme expliqué dans Deploying OpenStack once you have the OSP Director Operator installed
Deploying OpenStack once you have the OSP Director Operator installed et spécifiez le fichier de rôles généré des rôles. Remarque : Assurez-vous d'utiliser quay.io/openstack-k8s-operators/rhosp16-openstack-tripleoclient:16.2_20210521.1 ou ultérieure pour l'Osconfigenerator imageURL .
Attendez que l'OpenStackConfigenerator pour terminer le travail de rendu PlayBook.
Obtenez le hachage / digest de la dernière OpenStackConfigversion.
Créez un OpenStackDeploy pour l'OpenStackConfigversion spécifiée. Cela déploiera les manuels ANSIBL.
La suppression d'un hôte de calcul baremetal nécessite les étapes suivantes:
Dans le cas où un nœud de calcul est supprimé, désactivez le service de calcul sur le nœud sortant sur l'overcloud pour empêcher le nœud de planifier de nouvelles instances
openstack compute service list
openstack compute service set < hostname > nova-compute --disableAnnotation d'une ressource BMH
oc annotate -n openshift-machine-api bmh/openshift-worker-3 osp-director.openstack.org/delete-host=true --overwrite Le statut d'annotation se reflète dans l'OsbareMetalSet / OSVMSET en utilisant le paramètre annotatedForDeletion :
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 "
}
}La réduction du nombre de ressources de l'OsbareMetalt déclenchera le contrôleur CorrensPonding pour gérer la suppression des ressources
oc patch osbms computehci --type=merge --patch ' {"spec":{"count":1}} 'Par conséquent:
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
}
]
}Il en résulte le comportement suivant
À l'heure actuelle, si un nœud de calcul a été supprimé, il y a plusieurs entrées restantes enregistrées sur le plan de contrôle OpenStack et ne pas être nettoyées automatiquement. Pour les nettoyer, effectuez les étapes suivantes.
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 La suppression d'une machine virtuelle nécessite les étapes suivantes:
Si le VM héberge un service OSP qui doit être désactivé avant le retrait, faites-le.
Annotation d'une ressource VM
oc annotate -n openstack vm/controller-1 osp-director.openstack.org/delete-host=true --overwriteRéduire le RoleCount de ressources des VirtualMachineroles dans l'OpenStackControlPlane Cr. Le contrôleur CorrensPonding pour gérer la suppression des ressources
oc patch osctlplane overcloud --type=merge --patch ' {"spec":{"virtualMachineRoles":{"<RoleName>":{"roleCount":2}}}} 'Par conséquent:
Il en résulte le comportement suivant
Si la machine virtuelle a hébergé un service OSP qui doit être supprimé, supprimez le service à l'aide de la commande OpenStack correspondante.
Il est possible de déployer l'architecture des réseaux routés de Tripleo (réseautage de la colonne vertébrale / feuille) pour configurer les réseaux de feuilles Overcloud. Utilisez le paramètre des sous-réseaux pour définir les sous-réseaux de feuilles supplémentaires avec un réseau de base.
Une limitation en ce moment est qu'il ne peut y avoir qu'un seul réseau de provision pour Metal3.
Le workflow pour installer un OverCloud à l'aide de plusieurs sous-réseaux serait:
Définissez votre ressource personnalisée OpenStackNetConfig et spécifiez tous les sous-réseaux pour les réseaux Overcloud. L'opérateur rendra le Tripleo Network_data.yaml pour la version OSP utilisée.
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-ospSi vous écrivez le YAML ci-dessus dans un fichier appelé NetworkConfig.yaml, vous pouvez créer l'OpenStackNetConfig via cette commande:
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% '
... Mettez à jour le tarballConfigMap ConfigMap pour ajouter le fichier roles_data.yaml au Tarball et mettez à jour la configmap.
Remarque : assurez-vous d'utiliser roles_data.yaml comme nom de fichier.
Les modèles OSP 16.2 Tripleo NIC ont le paramètre Interfaceroutes par défaut inclus. Le paramètre Routes rendu dans les environnements / réseau-environnement.yaml qui sont nommés routes sont généralement définis sur la propriété Host_routes Network Nettron et sont ajoutés au paramètre Interfaceroutes de rôle. Puisqu'il n'y a pas de neutron, il est nécessaire d'ajouter les routes {{Network.name}} vers le modèle NIC si nécessaire et concat les deux listes:
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
Les informations sur le sous-réseau des routes sont rendues automatiquement dans les environments/network-environment.yaml qui est utilisé dans le script rendant les PlayBooks anibles. Dans les modèles NIC, utilisez donc Routes_ <Bnet_name>, par exemple Storageroutes_storage_leaf1 pour définir le routage correct sur l'hôte.
Pour un rôle de calcul computeaf1, le modèle NIC doit être modifié pour les utiliser:
...
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
... Mettez à jour la configmap tarballConfigMap pour ajouter le fichier NIC Templates roles_data.yaml au Tarball et mettez à jour la configmap.
Remarque : assurez-vous d'utiliser roles_data.yaml comme nom de fichier.
Jusqu'à présent, seul OSP16.2 a été testé avec un déploiement de sous-réseau multiples et est compatible avec le sous-réseau unique OSP17.0.
TBD
Assurez-vous d'ajouter les nouveaux modèles NIC créés au fichier environnement au resource_registry pour les nouveaux rôles de nœud:
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 À ce stade, nous pouvons provisionner l'overcoud.
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 : userpassword Définissez un OpenStackConfigenerator pour générer des PlayBooks ANSIBL pour le déploiement du cluster OSP comme dans Deploying OpenStack once you have the OSP Director Operator installed et spécifiez le fichier de rôles généré des rôles.
Comme décrit précédemment dans Run the software deployment , appliquez, enregistrez les nœuds Overcloud aux référentiels requis et exécutez le déploiement de sofware à l'intérieur du pod OpenStackClient.
L'opérateur OSP-D fournit une API pour créer et restaurer des sauvegardes de ses configurations CR, configmap et secrètes actuelles. Cette API se compose de deux CRD:
OpenStackBackupRequestOpenStackBackup Le CRD OpenStackBackupRequest est utilisé pour initier la création ou la restauration d'une sauvegarde, tandis que l' OpenStackBackup CRD est utilisé pour stocker réellement les données CR, configmap et secrètes qui appartiennent à l'opérateur. Cela permet plusieurs avantages:
OpenStackBackup CR, l'utilisateur n'a pas à exporter / importer manuellement chaque pièce de la configuration de l'opérateurOpenStackBackup , créez un OpenStackBackupRequest avec mode défini pour save dans ses spécifications. Par exemple: apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackBackupRequest
metadata :
name : openstackbackupsave
namespace : openstack
spec :
mode : save
additionalConfigMaps : []
additionalSecrets : []Les champs de spécification sont les suivants:
mode: save indique qu'il s'agit d'une demande de création d'une sauvegarde.additionalConfigMaps et additionalSecrets peuvent être utilisées pour inclure des configmaps et des secrets supplémentaires dont l'opérateur n'est pas au courant (c'est-à-dire des configmaps et des secrets créés manuellement à certaines fins).OpenStackControlPlane , OpenStackBaremetalSet , etc.) dans l'espace de noms, sans obliger l'utilisateur à les inclure dans ces listes supplémentaires.OpenStackBackupRequest créé, surveillez son statut: oc get -n openstack osbackuprequest openstackbackupsaveQuelque chose comme ça devrait apparaître:
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackupsave save Quiescing L'état Quiescing indique que l'opérateur attend que l'état d'approvisionnement de tous les CR de l'opérateur OSP-D atteignent leur équivalent "fini". Le temps requis pour cela variera en fonction de la quantité de CR de l'opérateur OSP-D et du hasard de leur état actuel d'approvisionnement. Remarque: Il est possible que l'opérateur ne s'allume jamais complètement en raison d'erreurs et / ou d'états "d'attente" dans le CRS existant. Pour voir quels CRD / CRS empêchent la quiese, étudiez les journaux de l'opérateur. Par exemple:
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] Si l' OpenStackBackupRequest entre dans l'état Error , regardez son contenu complet pour voir l'erreur qui a été rencontrée ( oc get -n openstack openstackbackuprequest <name> -o yaml ).
OpenStackBackupRequest a été honoré en créant et en enregistrant un OpenStackBackup représentant la configuration actuelle de l'opérateur OSP-D, il entrera dans l'état Saved . Par exemple: oc get -n openstack osbackuprequest
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackupsave save Saved 2022-01-11T19:12:58Z L' OpenStackBackup associé aura également été créé. Par exemple:
oc get -n openstack osbackup
NAME AGE
openstackbackupsave-1641928378 6m7sOpenStackBackup , créez un OpenStackBackupRequest avec mode défini pour restore dans ses spécifications. Par exemple: apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackBackupRequest
metadata :
name : openstackbackuprestore
namespace : openstack
spec :
mode : restore
restoreSource : openstackbackupsave-1641928378Les champs de spécification sont les suivants:
mode: restore indique qu'il s'agit d'une demande de restauration d'un OpenStackBackup existant.restoreSource indique quel OpenStackBackup doit être restauré. Avec mode défini sur restore , l'opérateur OSP-D prendra le contenu de la restoreSource OpenStackBackup et tentera de les appliquer par rapport aux CR, configmaps et secrets existants actuellement présents dans l'espace de noms. Ainsi, il écrasera toutes les ressources d'opérateur OSP-D existantes dans l'espace de noms avec les mêmes noms que ceux de l' OpenStackBackup , et créera de nouvelles ressources pour ceux qui ne sont pas trouvés actuellement dans l'espace de noms. Si vous le souhaitez, mode peut être défini sur cleanRestore pour effacer complètement les ressources de l'opérateur OSP-D existantes dans l'espace de noms avant de tenter une restauration, de sorte que toutes les ressources de l' OpenStackBackup sont complètement créées.
OpenStackBackupRequest créé, surveillez son statut: oc get -n openstack osbackuprequest openstackbackuprestore Quelque chose comme ça devrait sembler indiquer que toutes les ressources de l' OpenStackBackup sont appliquées contre le cluster:
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackuprestore restore openstackbackupsave-1641928378 Loading Ensuite, une fois que toutes les ressources ont été chargées, l'opérateur commencera à se réconcilier pour tenter de fournir toutes les ressources:
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackuprestore restore openstackbackupsave-1641928378 Reconciling Si l' OpenStackBackupRequest entre dans l'état Error , regardez son contenu complet pour voir l'erreur qui a été rencontrée ( oc get -n openstack openstackbackuprequest <name> -o yaml ).
OpenStackBackupRequest a été honoré en restaurant pleinement l' OpenStackBackup , il entrera dans l'état Restored . Par exemple: oc get -n openstack osbackuprequest
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackuprestore restore openstackbackupsave-1641928378 Restored 2022-01-12T13:48:57Z À ce stade, toutes les ressources contenues avec l' OpenStackBackup choisi doivent être restaurées et pleinement provisées.
L'opérateur OSP Director crée automatiquement une configMAP une fois que chaque ressource Osdeploy a fini l'exécution. Cette configmap est nommée d'après le nom de la ressource Osdeploy et préfixée avec Tripleo-Exports-. Par exemple, Tripleo-Exports-Default serait le nom de la configmap pour la ressource OSDeploy 'par défaut. Chaque configmap contient 2 fichiers YAML:
| Nom de fichier | Description | Tripleo Command équivalent |
|---|---|---|
| ctlplane-export.yaml | Utilisé avec plusieurs piles pour DCN | Exportation d'overcloud |
| ctlplane-export-filtor.yaml | Utilisé pour plusieurs piles avec des piles de "contrôleur" cellulaire | Exportation de cellules à l'overcoud |
Utilisez la commande ci-dessous pour extraire les fichiers YAML de la configmap. Une fois extrait, les fichiers YAML peuvent être ajoutés dans des paramètres de chaleur personnalisés sur les ressources Osconfigenerator.
oc extract cm/tripleo-exports-defaultRemarque: L'opérateur OSP Director ne génère pas encore des exportations pour les piles CEPH.
Si nécessaire, il est possible de modifier CPU / RAM d'un OpenStackVMSET configuré via OpenStackControlPlane. Le workflow est le suivant:
Par exemple pour changer le contrôleur virtualmachinerole pour avoir 8 cœurs et 22 Go de 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> pour ramener la machine virtuelle. Voir le document de processus de mise à jour OSP
