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
, orManila
. -
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
calledshare1
andshare2
. 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:
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>
- 1
- The
name
field is a string that names theextraMounts
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 theextraMounts
definition. This is an optional attribute. - 3
- The
propagation
field describes how the definition is applied. If thepropagation
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 theextraVol
entry of the list. There are no defined values for this parameter but the valuesCeph
,Nfs
, andUndefined
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 thevolumes
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 themounts
section. - 6
- The
mounts
field is a list of mountpoints that represent the path where thevolumeSource
should be mounted in the Pod. The name of a volume from thevolumes
section is used as a reference as well as the path where it should be mounted. This attribute has the same structure as thevolumeMounts
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 theOpenStackControlPlane
CR service definition.The following example demonstrates adding the
extraMounts
attribute:apiVersion: core.openstack.org/v1beta1 kind: OpenStackControlPlane metadata: name: openstack spec: extraMounts: - name: v1 region: r1 extraVol: extraVolType: Ceph
Add the
propagation
field to specify where in the service definition theextraMount
attribute applies.The following example adds the
propagation
field to the previous example:apiVersion: core.openstack.org/v1beta1 kind: OpenStackControlPlane metadata: name: openstack spec: glance: ... extraMounts: - name: v1 region: r1 extraVol: - propagation: 1 - Glance extraVolType: Ceph
- 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
, orGlanceAPI
maps.
-
Any back-end in the
Define the volume sources:
The following example demonstrates adding the
volumes
field to the previous example to provide a Red Hat Ceph Storage secret to the Image service (glance):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
- 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 previous example to provide the location and name of the file that contains the Red Hat Ceph Storage secret: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
- 1
- The
mounts
field with the location of the secrets file.
Update the control plane:
$ oc apply -f openstack_control_plane.yaml -n openstack
Wait until RHOCP creates the resources related to the
OpenStackControlPlane
CR. Run the following command to check the status:$ oc get openstackcontrolplane -n openstack
Tip
Append the
-w
option to the end of theoc 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:
$ oc get pods -n openstack
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.
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
Red Hat Ceph Storage
This configuration example defines the services that require access to the Red Hat Ceph Storage secret.
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
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.
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
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
.
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