If you choose external, no PVCs are created and the Image service acts like a stateless instance with no persistence provided. In this instance, persistence must be provided using extraMounts. NFS is often used to provide persistence. It can be mapped to /var/lib/glance:

...
default:
  storage:
    external: true
...
...
extraMounts:
- extraVol:
  - extraVolType: NFS
    mounts:
    - mountPath: /var/lib/glance/os_glance_staging_store
      name: nfs
    volumes:
    - name: nfs
      nfs:
        path: <nfs_export_path>
        server: <nfs_ip_address>

• Replace <nfs_export_path> with the export path of your NFS share.
• Replace <nfs_ip_address> with the IP address of your NFS share. This IP address must be part of the overlay network that is reachable by the Image service.

It should be noted that the configuration sample conflicts with the distributed image import feature. Distributed image import requires RWO storage plugged into a particular instance; it owns the data and receives requests in case its staged data is required for an upload operation. When the External model is adopted, if Red Hat Ceph Storage is used as a backend, and an image conversion operation is run in one of the existing replicas, the glance-operator does not have to make any assumption about the underlying storage that is tied to the staging area, and the conversion operation that uses the os_glance_staging_store directory (within the Pod) interacts with the RWX NFS backend provided via extraMounts. With this scenario, no image-cache PVC can be requested and mounted to a subPath, because it should be the administrator’s responsibility to plan for persistence by using extraMounts.

The PVC model is the default. When a GlanceAPI instance is deployed, a PVC is created and bound to /var/lib/glance according to the storageClass and storageRequest passed as input.

...
default:
  replicas: 3
  storage:
    storageRequest: 10G
...

In this model, if Red Hat Ceph Storage is set as a back end, no dedicated image conversion PVC is created. The administrator must think about the PVC sizing in advance; the size of the PVC should be at least up to the largest converted image size. Concurrent conversions within the same Pod might be problematic in terms of PVC size; a conversion will fail or cannot take place if the PVC is full and there’s not enough space. The upload should be retried after the previous conversion is over and the staging area space is released. However, concurrent conversion operations might happen in different Pods. You should deploy at least 3 replicas for a particular glanceAPI. This helps to handle heavy operations such as image conversion.

For a PVC-based layout, the scale out of a glanceAPI in terms of replicas is limited by the available storage provided by the storageClass, and depends on the storageRequest. The storageRequest is a critical parameter, it can be globally defined for all the glanceAPI, or defined with a different value for each API. It will influence the scale out operations for each of them. Other than a local PVC required for the staging area, it is possible to enable image cache, which is translated into an additional PVC bound to each glanceAPI instance. A glance-cache PVC is bound to /var/lib/glance/image-cache. The glance-operator configures the glanceAPI instance accordingly, setting both image_cache_max_size and the image_cache_dir parameters. The number of image cache PVCs follows the same rules described for the local PVC, and the number of requested PVCs is proportional to the number of replicas.

Parallel pod management tells the StatefulSet controller to launch or end all pods in parallel, and not wait for pods to become Running and Ready or completely terminated before launching or terminating another pod. This option only affects the behavior for scaling operations. Updates are not affected.

This is required to scale by more than one, including new deployments with more than one replica. All pods must be created at the same time. Otherwise, some PVCs will not be bound, the Object Storage service rings cannot be created, and pod startup will be blocked.

Object Storage service rings require information about the disks to use, and this includes sizes and hostnames or IPs. Sizes are not known when starting the StatefulSet by using PVCs. The size requirement is a lower limit, but the actual PVs might be much bigger.

The ring creation process works as follows:

• StatefulSets create PVCs before the ConfigMaps are available.
• The SwiftRing reconciler watches the SwiftStorage instances and iterates over PVCs to get actual information about the used disks.
• Once the PVCs are bound, the size is known and the swift-ring-rebalance job creates the Swift rings and the ConfigMap.
• StatefulSets wait for the ConfigMap to become available, then start the service pods.