Mount external files for configuration data

Use the extraMounts parameter to mount external files for configuration or authentication data in your Red Hat OpenStack Services on OpenShift (RHOSO) deployment, such as Red Hat Ceph Storage configuration files, external NFS shares, or storage back-end driver filesystems.

Example scenarios include:

  • Distributing Red Hat Ceph Storage cluster configuration and keyring files to Block Storage (cinder), Image (glance), and Compute (nova) services
  • Accessing external NFS shares for temporary image storage when node disk space is consumed
  • Configuring storage back-end drivers to run on persistent file systems to preserve data between reboots

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:

extraMounts:
  - name: <extramount-name>
    region: <openstack-region>
    extraVol:
      - propagation:
        - <location>
        extraVolType: <Ceph | Nfs | Undefined>
        volumes:
        - <pod-volume-structure>
        mounts:
        - <pod-mount-structure>
  • name 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.
  • region is a string that defines the RHOSO region of the extraMounts definition. This is an optional attribute.
  • propagation 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.
  • extraVolType 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.
  • volumes 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.
  • mounts 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 and the path where it should be mounted. This attribute has the same structure as the volumeMounts attribute for a Pod.

Mount external files with extraMounts

Configure the OpenStackControlPlane custom resource (CR) to access external data for configuration or authentication purposes in your Red Hat OpenStack Services on OpenShift (RHOSO) deployment.

Procedure

  1. Open your OpenStackControlPlane CR file, openstack_control_plane.yaml, on your workstation.
  2. Add the extraMounts attribute to the OpenStackControlPlane 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
  3. Add the propagation field to specify where in the service definition the extraMount 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:
              - Glance
              extraVolType: Ceph

    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.
  4. 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:
              - name: ceph
                secret:
                  secretName: ceph-conf-files

    where:

    ceph
    Is the Red Hat Ceph Storage secret name.
  5. 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:
              - name: ceph
                mountPath: "/etc/ceph"
                readOnly: true

    where:

    "/etc/ceph"
    Is the location of the secrets file.
  6. Update the control plane:
    $ oc apply -f openstack_control_plane.yaml -n openstack
  7. Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status:
    $ oc get openstackcontrolplane -n openstack

    The OpenStackControlPlane resources are created when the status is "Setup complete".

    Tip
    Append the -w option to the end of the get command to track deployment progress.
  8. 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.

extraMounts 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