13.10. Known Issues

The glusterfs_native driver allows users to create shares of specified sizes. If no Red Hat Gluster volumes of the exact requested size exist, the driver chooses one with the nearest possible size and creates a share on the volume. Whenever this occurs, the resulting share will use the entire volume.

For example, if a user requests a 1GB share and only 2GB, 3GB, and 4GB volumes are available, the driver will choose the 2GB volume as a back end for the share. The driver will also proceed with creating a 2GB share; the user will be able to use and mount the entire 2GB share.

With the glusterfs_native driver, providing or revoking cert-based access to a share restarts a Red Hat Gluster Storage volume. This, in turn, will disrupt any ongoing I/O to existing mounts. To prevent any data loss, unmount a share on all clients before allowing or denying access to it.

At present, policy rules for volume extension prevent you from taking snapshots of GlusterFS volumes currently in use. To work around this, you will have to manually edit those policy rules.

To do so, open the Compute service’s policy.json file and change "rule:admin_api" entries to "" for "compute_extension:os-assisted-volume-snapshots:create" and "compute_extension:os-assisted-volume-snapshots:delete". Afterwards, restart the Compute API service.

The manila list command shows information on all available shares. This command also shows the Export Location field of each one, which should provide information for composing its mount point entry in an instance. However, the field displays this information in the following format:

USER@HOST:/VOLUMENAME

The USER@ prefix is unnecessary, and should therefore be ignored when composing its mount point entry.

With the the File Share Service, when an attempt to create a snapshot of a provisioned share fails, an entry for the snapshot will still be created. However, this entry will be in an error state, and any attempts to delete it will fail.

When using the gluster_native driver, snapshot commands can fail ungracefully with a key error if any of the following components are down in the back end cluster’s nodes:

In addition, the following could also cause the same error:

Specifically, these issues can cause the openstack-manila-share service to produce a traceback with KeyError instead of producing a useful error message. When troubleshooting this error, consider these possible back end issues.

Attempting to mount a Red Hat Gluster Storage volume through FUSE from an OpenStack instance will fail. To work around this, you will need to configure the volume to allow client connections from insecure ports.

To do so, first add the entry option rpc-auth-allow-insecure on to /etc/glusterfs/glusterd.vol. Then, restart the glusterd service. Perform both steps for each Red Hat Gluster Storage node.

At this point, you should be able configure a volume to allow client connections from insecure ports. To do so, run the following commands:

# gluster vol stop VOLUMENAME && gluster vol start VOLUMENAME
# gluster vol set VOLUMENAME server.allow-insecure on

Run these two commands for every volume you need to mount through FUSE from an OpenStack instance.