90060722a9
This patch introduces a new directory layout in doc/source in conformance with the OpenStack manuals project migration spec [1], moves the existing content in manila/doc/source into the new directories, and adjusts index files accordingly. This is the first step in the migration process as outlined in the spec. [1] https://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html Partial-Bug: #1706181 Needed-By: I7924d94b82e7c8d9716bad7a219fc38c57970773 Depends-On: Ifc80fc56648cef74c85464321d1850e8c68449a0 Depends-On: Ia750cb049c0f53a234ea70ce1f2bbbb7a2aa9454 Change-Id: Ieea33262101a1d2459492c1c8aaac5fe042279f6
1.9 KiB
Introduction to the Shared File Systems service
Manila is the file share service project for OpenStack. Manila provides the management of file shares for example, NFS and CIFS as a core service to OpenStack. Manila works with a variety of proprietary backend storage arrays and appliances, with open source distributed filesystems, as well as with a base Linux NFS or Samba server. There are a number of concepts that will help in better understanding of the solutions provided by manila. One aspect can be to explore the different service possibilities provided by manila.
Manila, depending on the driver, requires the user by default to create a share network using neutron-net-id and neutron-subnet-id (GlusterFS native driver does not require it). After creation of the share network, the user can proceed to create the shares. Users in manila can configure multiple back-ends just like Cinder. Manila has a share server assigned to every tenant. This is the solution for all back-ends except for GlusterFS. The customer in this scenario is prompted to create a share server using neutron net-id and subnet-id before even trying to create a share.
The current low-level services available in manila are:
manila-apimanila-schedulermanila-share