The manila test applies to OpenStack products or components that implement features for the OpenStack Shared File System Storage service. The test uses Tempest Framework integrated with the Red Hat OpenStack Services on OpenShift (RHOSO) to test both operational and functional features.

The manila test verifies the functionality of the manila driver that you are certifying by running selected feature tests. The following feature groups are currently tested:

• manila-shr (required)
• manila-shr-managed (optional)
• manila-shr-shrink (optional)
• manila-shr-extend (required)
• manila-snap (optional)
• manila-snap-managed (optional)
• manila-shr-frm-snap (optional)
• manila-snap-revert (optional)
• manila-snap-mount (optional)
• manila-shr-replicas (optional)
• manila-shr-groups (required)
• manila-svr-managed (only for DHSS=True, optional)

Manila testing must include the tests defined in the test plan, covering the required tests and any implemented additional features.

Note

If you are certifying a backend that supports multiple driver modes, the “driver_handles_share_servers” (DHSS) attribute indicates these modes. DHSS is set to true or false. A backend can also support multiple storage protocols such as Network File System (NFS) and Common Internet File System (CIFS). You must adjust the test configuration to submit one test result per combination of driver mode and supported protocols. For example, a driver being certified can support both NFS and CIFS, and both DHSS=True and DHSS=False. If so, submit separate certification tests for each combination:

• DHSS=True with NFS.
• DHSS=False with NFS.
• DHSS=True with CIFS.
• DHSS=False with CIFS.

Prerequisites

1. When deploying the Control plane, ensure you provide at least two instances of the shared file system backend driver for certification. Note

   Having more than one hardware storage is not required; configuring both manila backends to use the same hardware array is supported.

2. Ensure you configure the separate manila backends on separate “manila-share” pods. Multi-backend configuration on a single pod was supported in earlier releases of RHOSP, but is no longer supported in RHOSO.
3. The rhoso-cert tooling will automatically detect and set some test configurations. However, manual adjustments may still be required to ensure that the features being tested are appropriately configured. These configurations should be specified in a file named tempest-conf-overrides. Note

   When defining custom configuration options, avoid setting options that could mask test failures, such as share.suppress_errors_in_cleanup.

4. In the RHOSO version, all manila tests are executed, including required and optional tests such as replication, managing snapshots, and so on. The optional tests may fail if your driver does not support those features. This is acceptable and does not impact the overall certification process.
5. When certifying a DHSS=True back end, ensure the following:
   1. When testing with NFS, ensure that the manila service is configured with NeutronNetworkPlugin or its derivative. The use of StandaloneNetworkPlugin is discouraged.
   2. When testing with CIFS, use of NeutronNetworkPlugin may be complicated if the authentication server is external to the cloud. The authentication server is typically an active directory server. You may use StandaloneNetworkPlugin in such a case to represent the datacenter storage networking.
   3. Create an accounts.yaml file for the rhcert tooling to use. This is essential to avoid cleanup errors in tempest tests.