Chapter 4. Deploying the DCN control plane To deploy Red Hat OpenStack Services on OpenShift (RHOSO) with a distributed compute node (DCN) architecture, you start with an installation of Red Hat OpenShift Container Platform (RHOCP) and install the RHOSO control plane. For details regarding preparation for the RHOSO control plane, see Preparing Red Hat OpenShift Container Platform for Red Hat OpenStack Services on OpenShift . Before you deploy the control plane, you must also configure the RHOCP networks. A DCN deployment of RHOSO requires the management of a larger number subnets. The subnets that you use are specific to your environment. This document uses the following configuration in each of its examples. Central location (AZ-0) AZ-1 AZ-2 Control plane 192.168.122.0/24 192.168.133.0/24 192.168.144.0/24 External 10.0.0.0/24 10.0.0.0/24 10.0.0.0/24 Internal 172.17.0.0/24 172.17.10.0/24 172.17.20.0/24 Storage 172.18.0.0/24 172.18.10.0/24 172.18.20.0/24 Tenant 172.19.0.0/24 172.19.10.0/24 172.19.20.0/24 Storage Management 172.20.0.0/24 172.20.10.0/24 172.20.20.0/24 4.1. Creating a spine-leaf network topology for DCN The geographically distributed nodes in a distributed compute node (DCN) architecture are interconnected using a routed spine-leaf network topology. You must configure the following CRs: NodeNetworkConfigurationPolicy Use the NodeNetworkConfigurationPolicy CR to configure the interfaces for each isolated network on each worker node in RHOCP cluster. NetworkAttachmentDefinition Use the NetworkAttachmentDefinition CR to attach service pods to the isolated networks, where needed. L2Advertisement Use the L2Advertisement resource to define how the Virtual IPs (VIPs) are announced. IPAddressPool Use the IPAddressPool resource to configure which IPs can be used as VIPs. NetConfig Use the NetConfig CR to specify the subnets for the data plane networks. OpenStackControlPlane Use the OpenStackControlPlane to define and configure OpenStack services on OpenShift. 4.2. Preparing DCN networking When you deploy a distributed compute node architecture, you deploy the central location control plane first. The Red Hat OpenStack Services on OpenShift (RHOSO) services run as a Red Hat OpenShift Container Platform (RHOCP) workload. Prerequisites The OpenStack Operator is installed Procedure Create a NodeNetworkConfigurationPolicy ( nncp ) CR definition file on your workstation for each worker node in the RHOCP cluster that hosts OpenStack services. In each nncp CR file, configure the interfaces for each isolated network. Each service interface must have its own unique address: Add the route-rules attribute and the route configuration to networks in each remote location to each nncp CR file: Note Each service network routes to the same network at each remote location. For example, the internapi network (172.17.0.0/24) has a route to the internalapi network at each remote location (172.17.10.0/24 and 172.17.20.0/24) through a local router at 172.17.0.1. Create the nncp CRs in the cluster: Create a NetworkAttachmentDefinition CR definition file for each network. Include routes to each remote location to the networks of the same function. For example, the internalapi NetworkAttachmentDefinition specifies its own subnet range as well as routes to the internalapi networks at remote sites. Create a NetworkAttachmentDefinition CR definition file for the internalapi network: Create a NetworkAttachmentDefinition CR definition file for the control network: Create a NetworkAttachmentDefinition CR definition file for the storage network: Create a NetworkAttachmentDefinition CR definition file for the tenant network: Create the NetworkAttachmentDefinition CRs: Create a NetConfig CR definition file to define which IPs can be used as Virtual IPs (VIPs). Each network defined under the dnsDomain field, with allocationRanges for each geographic reigon. These ranges cannot overlap with the whereabouts IPAM range. Create the file with the added allocation ranges for the control plane networking similar to the following: Add an allocation range for the internalapi network: Add an allocation range for the external network: Add an allocation range for the tenant network: Add an allocation range for the storagemgmt network: Create the NetConfig CR: 4.3. Creating the DCN control plane The Red Hat OpenStack Services on OpenShift (RHOSO) control plane contains the RHOSO services that manage the cloud. The RHOSO services run as a Red Hat OpenShift Container Platform (RHOCP) workload. Prerequisites The OpenStack Operator ( openstack-operator ) is installed. The RHOCP cluster is prepared for RHOSO networks. The RHOCP cluster is not configured with any network policies that prevent communication between the openstack-operators namespace and the control plane namespace (default openstack ). Use the following command to check the existing network policies on the cluster: You are logged on to a workstation that has access to the RHOCP cluster, as a user with cluster-admin privileges. Procedure Create a file on your workstation named openstack_control_plane.yaml to define the OpenStackControlPlane CR: Use the spec field to specify the Secret CR you create to provide secure access to your pod, and the storageClass you create for your Red Hat OpenShift Container Platform (RHOCP) cluster storage back end: Replace <RHOCP_storage_class> with the storage class you created for your RHOCP cluster storage back end. Add service configurations. Include service configurations for all required services: Block Storage service (cinder): Note In RHOSO 18.0.3, You must set the uniquePodNames field to a value of false to allow for the propagation of Secrets. For more information see OSPRH-11240 . Note Set the replicas field to a value of 0 . The replica count is changed and additional cinderVolume services are added after storage is configured. Set the storage_availability_zone field in the template section to az0 . All Block storage service (cinder) pods inherit this value, such as cinderBackup , cinderVolume , and so on. You can override this AZ for the cinderVolume service by specifying the backend_availability_zone . Compute service (nova): DNS service for the data plane: Galera Identity service (keystone) Image service (glance): Note You must initially set the replicas field to a value of 0 . The replica count is changed and additional glanceAPI services are added after storage is configured. Key Management service (barbican): Memcached Networking service (neutron): 1 Set the network_scheduler_driver to a value of neutron.scheduler.dhcp_agent_scheduler.AZAwareWeightScheduler if a DHCP agent is deployed. OVN Placement service (placement) RabbitMQ Create the control plane: Additional resources Providing secure access to the Red Hat OpenStack Services on OpenShift services Creating a storage class Creating the control plane 4.4. Ceph secret key site distribution When you deploy a distributed compute node (DCN) environment with multiple Ceph backends, you create a Ceph key for each backend. For security purposes, distribute the least number of Ceph keys to each site. Create one secret for each location. Add the key for each Ceph backend to the secret for the default location. Add the the key for the default Ceph backend, as well as the local ceph backend for each additional location. For three locations, az0 , az1 , and az2 , you must have three secrets. Locations az1 and az2 each have keys for the local backend as well as the keys for az0 . Location az0 contains all Ceph back end keys. Procedure You create the required secrets after Ceph has been deployed at each edge location, and the keyring and configuration file for each has been collected. Alternatively, you can deploy each Ceph backend as needed, and update secrets with each edge deployment. Create a secret for location az0 . If you have already deployed Red Hat Ceph Storage (RHCS) at all edge sites which require storage, create a secret for az0 which contains all keyrings and conf files: If you have not deployed RHCS at all edge sites, create a secret for az0 which contains the keyring and conf file for az0 : When you deploy RHCS at the edge location at availability zone 1 ( az1 ), create a secret for location az1 which contains keyrings and conf files for the local backend, and the default backend: If needed, update the secret for the central location: When you deploy RHCS at the edge location at availability zone 2 ( az2 ) create a secret for location az2 which contains keyrings and conf files for the local backend, and the default backend: If needed, update the secret for the central location: [Optional] When you have finished creating the necessary keys, you can verify that they show up in the openstack namespace: Example output When you create an OpenStackDataPlaneNodeSet , use the appropriate key under the extraMounts field: When you create a data plane NodeSet, you must also update the OpenStackControlPlane custom resource (CR) with the secret name: Note If the CinderBackup service is a part of the deployment, then you must include it in the propagation list because it does not have the availability zone in its pod name. When you update the glanceAPIs field in the OpenStackControlPlane CR, the Image service (glance) pod name matches the extraMounts propagation instances: When you update the cinderVolumes field in the OpenStackControlPlane CR, the Block Storage service (cinder) pod names must also match the extraMounts propagation instance s:

Commands:
apiVersion: nmstate.io/v1 kind: NodeNetworkConfigurationPolicy metadata: labels: osp/nncm-config-type: standard name: worker-0 namespace: openstack spec: desiredState: dns-resolver: config: search: [] server: - 192.168.122.1 interfaces: - description: internalapi vlan interface ipv4: address: - ip: 172.17.0.10 prefix-length: "24" dhcp: false enabled: true ipv6: enabled: false mtu: 1496 name: internalapi state: up type: vlan vlan: base-iface: enp7s0 id: "20" - description: storage vlan interface ipv4: address: - ip: 172.18.0.10 prefix-length: "24" dhcp: false enabled: true ipv6: enabled: false mtu: 1496 name: storage state: up type: vlan vlan: base-iface: enp7s0 id: "21" - description: tenant vlan interface ipv4: address: - ip: 172.19.0.10 prefix-length: "24" dhcp: false enabled: true ipv6: enabled: false mtu: 1496 name: tenant state: up type: vlan vlan: base-iface: enp7s0 id: "22" - description: ctlplane interface mtu: 1500 name: enp7s0 state: up type: ethernet - bridge: options: stp: enabled: false port: - name: enp7s0 vlan: {} description: linux-bridge over ctlplane interface ipv4: address: - ip: 192.168.122.10 prefix-length: "24" dhcp: false enabled: true ipv6: enabled: false mtu: 1500 name: ospbr state: up type: linux-bridge
route-rules: config: [] routes: config: - destination: 192.168.133.0/24 next-hop-address: 192.168.122.1 next-hop-interface: ospbr table-id: 254 - destination: 192.168.144.0/24 next-hop-address: 192.168.122.1 next-hop-interface: ospbr table-id: 254 - destination: 172.17.10.0/24 next-hop-address: 172.17.0.1 next-hop-interface: internalapi table-id: 254 - destination: 172.18.10.0/24 next-hop-address: 172.18.0.1 next-hop-interface: storage table-id: 254 - destination: 172.19.10.0/24 next-hop-address: 172.19.0.1 next-hop-interface: tenant table-id: 254 - destination: 172.17.20.0/24 next-hop-address: 172.17.0.1 next-hop-interface: internalapi table-id: 254 - destination: 172.18.20.0/24 next-hop-address: 172.18.0.1 next-hop-interface: storage table-id: 254 - destination: 172.19.20.0/24 next-hop-address: 172.19.0.1 next-hop-interface: tenant table-id: 254 nodeSelector: kubernetes.io/hostname: worker-0 node-role.kubernetes.io/worker: ""
oc create -f worker0-nncp.yaml oc create -f worker1-nncp.yaml oc create -f worker2-nncp.yaml
apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: labels: osp/net: internalapi osp/net-attach-def-type: standard name: internalapi namespace: openstack spec: config: | { "cniVersion": "0.3.1", "name": "internalapi", "type": "macvlan", "master": "internalapi", "ipam": { "type": "whereabouts", "range": "172.17.0.0/24", "range_start": "172.17.0.30", "range_end": "172.17.0.70", "routes": [ { "dst": "172.17.10.0/24", "gw": "172.17.0.1" }, { "dst": "172.17.20.0/24", "gw": "172.17.0.1" } ] } }
apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: labels: osp/net: ctlplane osp/net-attach-def-type: standard name: ctlplane namespace: openstack spec: config: | { "cniVersion": "0.3.1", "name": "ctlplane", "type": "macvlan", "master": "ospbr", "ipam": { "type": "whereabouts", "range": "192.168.122.0/24", "range_start": "192.168.122.30", "range_end": "192.168.122.70", "routes": [ { "dst": "192.168.133.0/24", "gw": "192.168.122.1" }, { "dst": "192.168.144.0/24", "gw": "192.168.122.1" } ] } }
apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: labels: osp/net: storage osp/net-attach-def-type: standard name: storage namespace: openstack spec: config: | { "cniVersion": "0.3.1", "name": "storage", "type": "macvlan", "master": "storage", "ipam": { "type": "whereabouts", "range": "172.18.0.0/24", "range_start": "172.18.0.30", "range_end": "172.18.0.70", "routes": [ { "dst": "172.18.10.0/24", "gw": "172.18.0.1" }, { "dst": "172.18.20.0/24", "gw": "172.18.0.1" } ] } }
apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: labels: osp/net: tenant osp/net-attach-def-type: standard name: tenant namespace: openstack spec: config: | { "cniVersion": "0.3.1", "name": "tenant", "type": "macvlan", "master": "tenant", "ipam": { "type": "whereabouts", "range": "172.19.0.0/24", "range_start": "172.19.0.30", "range_end": "172.19.0.70", "routes": [ { "dst": "172.19.10.0/24", "gw": "172.19.0.1" }, { "dst": "172.19.20.0/24", "gw": "172.19.0.1" } ] } }
oc create -f internalapi-net-attach-def.yaml oc create -f control-net-attach-def.yaml oc create -f storage-net-attach-def.yaml oc create -f tenant-net-attach-def.yaml
apiVersion: network.openstack.org/v1beta1 kind: NetConfig metadata: name: netconfig namespace: openstack spec: networks: - dnsDomain: ctlplane.example.com mtu: 1500 name: ctlplane subnets: - allocationRanges: - end: 192.168.122.120 start: 192.168.122.100 - end: 192.168.122.170 start: 192.168.122.150 cidr: 192.168.122.0/24 gateway: 192.168.122.1 name: subnet1 routes: - destination: 192.168.133.0/24 nexthop: 192.168.122.1 - destination: 192.168.144.0/24 nexthop: 192.168.122.1 - allocationRanges: - end: 192.168.133.120 start: 192.168.133.100 - end: 192.168.133.170 start: 192.168.133.150 cidr: 192.168.133.0/24 gateway: 192.168.133.1 name: subnet2 routes: - destination: 192.168.122.0/24 nexthop: 192.168.133.1 - destination: 192.168.144.0/24 nexthop: 192.168.133.1 - allocationRanges: - end: 192.168.144.120 start: 192.168.144.100 - end: 192.168.144.170 start: 192.168.144.150 cidr: 192.168.144.0/24 gateway: 192.168.144.1 name: subnet3 routes: - destination: 192.168.122.0/24 nexthop: 192.168.144.1 - destination: 192.168.133.0/24 nexthop: 192.168.144.1
- dnsDomain: internalapi.example.com mtu: 1496 name: internalapi subnets: - allocationRanges: - end: 172.17.0.250 start: 172.17.0.100 cidr: 172.17.0.0/24 name: subnet1 routes: - destination: 172.17.10.0/24 nexthop: 172.17.0.1 - destination: 172.17.20.0/24 nexthop: 172.17.0.1 vlan: 20 - allocationRanges: - end: 172.17.10.250 start: 172.17.10.100 cidr: 172.17.0.0/24 name: subnet2 routes: - destination: 172.17.0.0/24 nexthop: 172.17.10.1 - destination: 172.17.20.0/24 nexthop: 172.17.10.1 vlan: 30 - allocationRanges: - end: 172.17.20.250 start: 172.17.20.100 cidr: 172.17.20.0/24 name: subnet3 routes: - destination: 172.17.0.0/24 nexthop: 172.17.20.1 - destination: 172.17.10.0/24 nexthop: 172.17.20.1 vlan: 40
- dnsDomain: external.example.com mtu: 1500 name: external subnets: - allocationRanges: - end: 10.0.0.250 start: 10.0.0.100 cidr: 10.0.0.0/24 name: subnet1 vlan: 22 - dnsDomain: storage.example.com mtu: 1496 name: storage subnets: - allocationRanges: - end: 172.18.0.250 start: 172.18.0.100 cidr: 172.18.0.0/24 name: subnet1 routes: - destination: 172.18.10.0/24 nexthop: 172.18.0.1 - destination: 172.18.20.0/24 nexthop: 172.18.0.1 vlan: 21 - allocationRanges: - end: 172.18.10.250 start: 172.18.10.100 cidr: 172.18.10.0/24 name: subnet2 routes: - destination: 172.18.0.0/24 nexthop: 172.18.10.1 - destination: 172.18.20.0/24 nexthop: 172.18.10.1 vlan: 31 - allocationRanges: - end: 172.18.20.250 start: 172.18.20.100 cidr: 172.18.20.0/24 name: subnet3 routes: - destination: 172.18.0.0/24 nexthop: 172.18.20.1 - destination: 172.18.10.0/24 nexthop: 172.18.20.1 vlan: 41
- dnsDomain: tenant.example.com mtu: 1496 name: tenant subnets: - allocationRanges: - end: 172.19.0.250 start: 172.19.0.100 cidr: 172.19.0.0/24 name: subnet1 routes: - destination: 172.19.10.0/24 nexthop: 172.19.0.1 - destination: 172.19.20.0/24 nexthop: 172.19.0.1 vlan: 22 - allocationRanges: - end: 172.19.10.250 start: 172.19.10.100 cidr: 172.19.10.0/24 name: subnet2 routes: - destination: 172.19.0.0/24 nexthop: 172.19.10.1 - destination: 172.19.20.0/24 nexthop: 172.19.10.1 vlan: 32 - allocationRanges: - end: 172.19.20.250 start: 172.19.20.100 cidr: 172.19.20.0/24 name: subnet3 routes: - destination: 172.19.0.0/24 nexthop: 172.19.20.1 - destination: 172.19.10.0/24 nexthop: 172.19.20.1 vlan: 42
- dnsDomain: storagemgmt.example.com mtu: 1500 name: storagemgmt subnets: - allocationRanges: - end: 172.20.0.250 start: 172.20.0.100 cidr: 172.20.0.0/24 name: subnet1 routes: - destination: 172.20.10.0/24 nexthop: 172.20.0.1 - destination: 172.20.20.0/24 nexthop: 172.20.0.1 vlan: 23 - allocationRanges: - end: 172.20.10.250 start: 172.20.10.100 cidr: 172.20.10.0/24 name: subnet2 routes: - destination: 172.20.0.0/24 nexthop: 172.20.10.1 - destination: 172.20.20.0/24 nexthop: 172.20.10.1 vlan: 33 - allocationRanges: - end: 172.20.20.250 start: 172.20.20.100 cidr: 172.20.20.0/24 name: subnet3 routes: - destination: 172.20.0.0/24 nexthop: 172.20.20.1 - destination: 172.20.10.0/24 nexthop: 172.20.20.1 vlan: 43
create -f netconfig
oc get networkpolicy -n openstack
apiVersion: core.openstack.org/v1beta1 kind: OpenStackControlPlane metadata: name: openstack-control-plane namespace: openstack
apiVersion: core.openstack.org/v1beta1 kind: OpenStackControlPlane metadata: name: openstack-control-plane namespace: openstack spec: secret: osp-secret storageClass: <RHOCP_storage_class>
cinder: uniquePodNames: false apiOverride: route: {} template: customServiceConfig: | [DEFAULT] storage_availability_zone = az0 databaseInstance: openstack secret: osp-secret cinderAPI: replicas: 3 override: service: internal: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/allow-shared-ip: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.80 spec: type: LoadBalancer cinderScheduler: replicas: 1 cinderVolumes: az0: networkAttachments: - storage replicas: 0
nova: apiOverride: route: {} template: apiServiceTemplate: replicas: 3 override: service: internal: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/allow-shared-ip: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.80 spec: type: LoadBalancer metadataServiceTemplate: replicas: 3 override: service: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/allow-shared-ip: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.80 spec: type: LoadBalancer schedulerServiceTemplate: replicas: 3 override: service: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/allow-shared-ip: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.80 spec: type: LoadBalancer cellTemplates: cell0: cellDatabaseAccount: nova-cell0 cellDatabaseInstance: openstack cellMessageBusInstance: rabbitmq hasAPIAccess: true cell1: cellDatabaseAccount: nova-cell1 cellDatabaseInstance: openstack-cell1 cellMessageBusInstance: rabbitmq-cell1 noVNCProxyServiceTemplate: enabled: true networkAttachments: - ctlplane hasAPIAccess: true secret: osp-secret
dns: template: options: - key: server values: - 192.168.122.1 - key: server values: - 192.168.122.2 override: service: metadata: annotations: metallb.universe.tf/address-pool: ctlplane metallb.universe.tf/allow-shared-ip: ctlplane metallb.universe.tf/loadBalancerIPs: 192.168.122.80 spec: type: LoadBalancer replicas: 2
galera: templates: openstack: storageRequest: 5000M secret: osp-secret replicas: 3 openstack-cell1: storageRequest: 5000M secret: osp-secret replicas: 3
keystone: apiOverride: route: {} template: override: service: internal: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/allow-shared-ip: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.80 spec: type: LoadBalancer databaseInstance: openstack secret: osp-secret replicas: 3
glance: apiOverrides: default: route: {} template: databaseInstance: openstack storage: storageRequest: 10G secret: osp-secret keystoneEndpoint: default glanceAPIs: default: replicas: 0 override: service: internal: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/allow-shared-ip: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.80 spec: type: LoadBalancer networkAttachments: - storage
barbican: apiOverride: route: {} template: databaseInstance: openstack secret: osp-secret barbicanAPI: replicas: 3 override: service: internal: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/allow-shared-ip: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.80 spec: type: LoadBalancer barbicanWorker: replicas: 3 barbicanKeystoneListener: replicas: 1
memcached: templates: memcached: replicas: 3
neutron: apiOverride: route: {} template: customServiceConfig: | [DEFAULT] network_scheduler_driver = neutron.scheduler.dhcp_agent_scheduler.AZAwareWeightScheduler 1 default_availability_zones = az0 [ml2_type_vlan] network_vlan_ranges = datacentre:1:1000 [neutron] physnets = datacentre replicas: 3 override: service: internal: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/allow-shared-ip: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.80 spec: type: LoadBalancer databaseInstance: openstack secret: osp-secret networkAttachments: - internalapi
ovn: template: ovnController: external-ids" availability-zones: - az0 enable-chassis-as-gateway: true ovn-bridge: br-int ovn-encap-type: geneve system-id: random networkAttachment: tenant nicMappings: datacentre: ospbr ovnDBCluster: ovndbcluster-nb: replicas: 3 dbType: NB storageRequest: 10G networkAttachment: internalapi ovndbcluster-sb: replicas: 3 dbType: SB storageRequest: 10G networkAttachment: internalapi ovnNorthd: networkAttachment: internalapi
placement: apiOverride: route: {} template: override: service: internal: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/allow-shared-ip: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.80 spec: type: LoadBalancer databaseInstance: openstack replicas: 3 secret: osp-secret
rabbitmq: templates: rabbitmq: replicas: 3 override: service: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.85 spec: type: LoadBalancer rabbitmq-cell1: replicas: 3 override: service: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.86 spec: type: LoadBalancer
create -f openstack_control_plane.yaml -n openstack
create secret generic ceph-conf-az-0 --from-file=az0.client.openstack.keyring --from-file=az0.conf --from-file=az1.client.openstack.keyring --from-file=az1.conf --from-file=az2.client.openstack.keyring --from-file=az2.conf -n openstack
create secret generic ceph-conf-az-0 --from-file=az0.client.openstack.keyring --from-file=az0.conf -n openstack
create secret generic ceph-conf-az-1 --from-file=az0.client.openstack.keyring --from-file=az0.conf --from-file=az1.client.openstack.keyring --from-file=az1.conf -n openstack
delete secret ceph-conf-az-0 -n openstack create secret generic ceph-conf-az-0 --from-file=az0.client.openstack.keyring --from-file=az0.conf --from-file=az1.client.openstack.keyring --from-file=az1.conf -n openstack
create secret generic ceph-conf-az-2 --from-file=az0.client.openstack.keyring --from-file=az0.conf --from-file=az2.client.openstack.keyring --from-file=az2.conf -n openstack
delete secret ceph-conf-az-0 -n openstack create secret generic ceph-conf-az-0 --from-file=az0.client.openstack.keyring --from-file=az0.conf --from-file=az1.client.openstack.keyring --from-file=az1.conf --from-file=az1.client.openstack.keyring --from-file=az1.conf --from-file=az2.client.openstack.keyring --from-file=az2.conf
get secret -n openstack -o name | grep ceph-conf
secret/ceph-conf-az-0 secret/ceph-conf-az-1 secret/ceph-conf-az-2
apiVersion: dataplane.openstack.org/v1beta1 kind: OpenStackDataPlaneNodeSet metadata: name: openstack-edpm-dcn-0 namespace: openstack spec: nodeTemplate: extraMounts: - extraVolType: Ceph volumes: - name: ceph secret: secretName: ceph-conf-az-0 mounts: - name: ceph mountPath: "/etc/ceph" readOnly: true
apiVersion: core.openstack.org/v1beta1 kind: OpenStackControlPlane spec: extraMounts: - name: v1 region: r1 extraVol: - propagation: - az0 - CinderBackup extraVolType: Ceph volumes: - name: ceph secret: name: ceph-conf-az-0 mounts: - name: ceph mountPath: "/etc/ceph" readOnly: true - propagation: - az1 extraVolType: Ceph volumes: - name: ceph secret: name: ceph-conf-az-1 mounts: - name: ceph mountPath: "/etc/ceph" readOnly: true
glanceAPIs: az0: customServiceConfig: | az1: customServiceConfig: |
kind: OpenStackControlPlane spec: <...> cinder <...> cinderVolumes: az0: <...> az1: <...>