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:

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 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

  1. Open your OpenStackControlPlane custom resource (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: 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 , 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: 1
              - name: ceph
                secret:
                  secretName: ceph-conf-files
    1
    The volumes field with 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: 1
              - name: ceph
                mountPath: "/etc/ceph"
                readOnly: true
    1
    The mounts field with 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

    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".

  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.

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
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.