Chapter 2. Mounting external files to provide configuration data Some deployment scenarios require access to external data for configuration or authentication purposes. RHOSO provides the extraMounts parameter to allow access to this external information. This parameter mounts the designated external file for use by the RHOSO deployment. Deployment scenarios that require external information of this type can include: A component needs deployment-specific configuration and credential files for the storage back-end to exist in a specific location in the filesystem. For example, the Red Hat Ceph Storage cluster configuration and keyring files are required by the Block Storage (cinder), Image (glance) and Compute (nova) services. These configuration and keyring files must be distributed to these services using the extraMounts parameter. A node requires access to an external NFS share to use as a temporary image storage location when the allocated node disk space is fully consumed. You use the extraMounts parameter to configure this access. For example, the Block Storage service using an external share to perform conversion. A storage back-end drive must run on a persistent filesystem to preserve stored data between reboots. You must use the extraMounts parameter to configure this runtime location. The extraMounts parameter can be defined at the following levels: Service - A Red Hat OpenStack Services on OpenShift (RHOSO) service such as Glance , Cinder , or Manila . Component - A component of a service such as GlanceAPI , CinderAPI , CinderScheduler , ManilaShare , CinderBackup . Instance - An individual instance of a particular component. For example, your deployment could have two instances of the component ManilaShare called share1 and share2 . An Instance level propagation represents the Pod associated to an instance that is part of the same Component type. The propagation field is used to describe how the definition is applied. If the propagation field is not used, definitions propagate to every level below the level at which it is defined: Service level definitions propagate to Component and Instance levels. Component level definitions propagate to the Instance level. The following is the general structure of an extraMounts definition: 1 The name field is a string that names the extraMounts definition. This is for organizational purposes and cannot be referenced from other parts of the manifest. This is an optional attribute. 2 The region field is a string that defines the RHOSO region of the extraMounts definition. This is an optional attribute. 3 The propagation field describes how the definition is applied. If the propagation field is not used, definitions propagate to every level below the level at which it is defined. This is an optional attribute. 4 The extraVolType field is a string that assists the administrator in categorizing or labeling the group of mounts that belong to the extraVol entry of the list. There are no defined values for this parameter but the values Ceph , Nfs , and Undefined are common. This is an optional attribute. 5 The volumes field is a list that defines Red Hat OpenShift volume sources. This field has the same structure as the volumes section in a Pod. The structure is dependent on the type of volume being defined. The name defined in this section is used as a reference in the mounts section. 6 The mounts field is a list of mountpoints that represent the path where the volumeSource should be mounted in the Pod. The name of a volume from the volumes section is used as a reference as well as the path where it should be mounted. This attribute has the same structure as the volumeMounts attribute for a Pod. 2.1. Mounting external files using the extraMounts attribute Procedure Open your OpenStackControlPlane custom resource (CR) file, openstack_control_plane.yaml , on your workstation. Add the extraMounts attribute to the OpenStackControlPlane CR service definition. The following example demonstrates adding the extraMounts attribute: Add the propagation field to specify where in the service definition the extraMount attribute applies. The following example adds the propagation field to the example: 1 The propagation field can have one of the following values: Service level propagations: Glance Cinder Manila Horizon Neutron Component level propagations: CinderAPI CinderScheduler CinderVolume CinderBackup GlanceAPI ManilaAPI ManilaScheduler ManilaShare NeutronAPI Back-end propagation: Any back-end in the CinderVolume , ManilaShare , or GlanceAPI maps. Define the volume sources: The following example demonstrates adding the volumes field to the example to provide a Red Hat Ceph Storage secret to the Image service (glance): 1 The volumes field with the Red Hat Ceph Storage secret name. Define where the different volumes are mounted within the Pod. The following example demonstrates adding the mounts field to the example to provide the location and name of the file that contains the Red Hat Ceph Storage secret: 1 The mounts field with the location of the secrets file. Update the control plane: Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status: Tip Append the -w option to the end of the oc get command to track deployment progress. The OpenStackControlPlane resources are created when the status is "Setup complete". Confirm that the control plane is deployed by reviewing the pods in the openstack namespace: The control plane is deployed when all the pods are either completed or running. 2.2. Mounting external files configuration examples The following configuration examples demonstrate how the extraMounts attribute is used to mount external files. The extraMounts attribute is defined at either the top level custom resource ( spec ) or the service definition. Dashboard service (horizon) This configuration example demonstrates using an external file to provide configuration to the Dashboard service. Red Hat Ceph Storage This configuration example defines the services that require access to the Red Hat Ceph Storage secret. Shared File Systems service (manila) This configuration example provides external configuration files to the Shared File Systems service so that it can connect to a Red Hat Ceph Storage back end. Image service (glance) This configuration example connects three glanceAPI instances to a different Red Hat Ceph Storage back end. The instances; api0 , api1 , and api2 ; are connected to three different Red Hat Ceph Storage clusters that are named ceph0 , ceph1 , and ceph2 .

Commands:
extraMounts: - name: <extramount-name> 1 region: <openstack-region> 2 extraVol: - propagation: 3 - <location> extraVolType: <Ceph | Nfs | Undefined> 4 volumes: 5 - <pod-volume-structure> mounts: 6 - <pod-mount-structure>
apiVersion: core.openstack.org/v1beta1 kind: OpenStackControlPlane metadata: name: openstack spec: extraMounts: - name: v1 region: r1 extraVol: extraVolType: Ceph
apiVersion: core.openstack.org/v1beta1 kind: OpenStackControlPlane metadata: name: openstack spec: glance: extraMounts: - name: v1 region: r1 extraVol: - propagation: 1 - Glance extraVolType: Ceph
apiVersion: core.openstack.org/v1beta1 kind: OpenStackControlPlane metadata: name: openstack spec: extraMounts: - name: v1 region: r1 extraVol: extraVolType: Ceph volumes: 1 - name: ceph secret: secretName: ceph-conf-files
apiVersion: core.openstack.org/v1beta1 kind: OpenStackControlPlane metadata: name: openstack spec: extraMounts: - name: v1 region: r1 extraVol: extraVolType: Ceph volumes: - name: ceph secret: secretName: ceph-conf-files mounts: 1 - name: ceph mountPath: "/etc/ceph" readOnly: true
oc apply -f openstack_control_plane.yaml -n openstack
oc get openstackcontrolplane -n openstack
oc get pods -n openstack
apiVersion: core.openstack.org/v1beta1 kind: OpenStackControlPlane spec: horizon: enabled: true template: customServiceConfig: '# add your customization here' extraMounts: - extraVol: - extraVolType: HorizonSettings mounts: - mountPath: /etc/openstack-dashboard/local_settings.d/_66_help_link.py name: horizon-config readOnly: true subPath: _66_help_link.py volumes: - name: horizon-config configMap: name: horizon-config
apiVersion: core.openstack.org/v1beta1 kind: OpenStackControlPlane spec: extraMounts: - name: v1 region: r1 extraVol: - propagation: - CinderVolume - CinderBackup - GlanceAPI - ManilaShare extraVolType: Ceph volumes: - name: ceph secret: secretName: ceph-conf-files mounts: - name: ceph mountPath: "/etc/ceph" readOnly: true
apiVersion: core.openstack.org/v1beta1 kind: OpenStackControlPlane apiVersion: core.openstack.org/v1beta1 spec: manila: template: ManilaShares: share1: extraMounts: - name: v1 region: r1 extraVol: - propagation: - share1 extraVolType: Ceph volumes: - name: ceph secret: secretName: ceph-conf-files mounts: - name: ceph mountPath: "/etc/ceph" readOnly: true
apiVersion: core.openstack.org/v1beta1 kind: OpenStackControlPlane spec: extraMounts: - name: api0 region: r1 extraVol: - propagation: - api0 volumes: - name: ceph0 secret: secretName: <secret_name> mounts: - name: ceph0 mountPath: "/etc/ceph" readOnly: true - name: api1 region: r1 extraVol: - propagation: - api1 volumes: - name: ceph1 secret: secretName: <secret_name> mounts: - name: ceph1 mountPath: "/etc/ceph" readOnly: true - name: api2 region: r1 extraVol: - propagation: - api2 volumes: - name: ceph2 secret: secretName: <secret_name> mounts: - name: ceph2 mountPath: "/etc/ceph" readOnly: true