Jump to: navigation, search

Difference between revisions of "Manila/design"

(Sub Pages)
Line 58: Line 58:
  
  
{{Special:PrefixIndex/:Manila/design|hideredirects=1}}
+
{{Special:PrefixIndex/:Manila/QoS|hideredirects=1}}

Revision as of 03:31, 11 November 2015

Components / Phases

The original master blueprint is here: File Shares Service

1) File Shares Service

The service was initially conceived as an addition of a separate File Share Service, albeit delivered within the Cinder (OpenStack Block Storage) project given the opportunity to make use of common code. In June of 2013, however, the decision was made to establish an independent development project to accommodate:

  • Creation of file system shares (e.g. the create API needs to support a "protocol" & a permissions "mask" and "ownership" parameters)
  • Deletion of file systems shares
  • List, show, provide and deny access, & list share access rules to file system shares
  • Create, list, and delete snapshots / clones of file systems shares
  • Coordination of mounting file system shares
  • Unmounting file systems shares

Implementation status: development underway in [[1]]

Manila API Documentation Manila API Roadmap Manila Database Specification

NOTE: Manila started as a fork of Cinder given that it provides facility for many of the concepts that a File Shares service would depend upon. The present Cinder concepts of capacity, target (server in NAS parlance), initiator (likewise the client when referring to shared file systems) are common conceptually (if not entirely semantically) and broadly applicable to both block and file-based storage. Specific Cinder capabilities (such as the filter scheduler, the notion of type, and extra specs) likewise apply to provisioning shared file systems as well. The initial prototype of the File Share Service is thus based on an evolution of Cinder. Manila, however, addresses a variety of additional concerns that aren't relevant to Cinder operation. After discussion within the Cinder community and consultation with members of the Technical Committee it was determined that establishing a separate project expressly designed and developed to deliver shared / distributed file systems as a service was the most viable approach. The intention is to move any commonality between Cinder and the File Share Service into Oslo where sensible.

2) Manila Reference Provider(s)

Creation of a reference Manila provider (commonly also referred to as a driver) for shared file system use under the proposed expanded API. As an example, a NetApp provider for this would be able to advertise, accept, and respond to requests for NFSv3, NFSv4, NFSv4.1 (w/ pNFS), & contemporary CIFS / SMB protocols (eg versions 2, 2.1, 3). Additional modification of python-cinderclient will be necessary to provide for the expanded array of request parameters. Both a vendor independent reference and NetApp-specific backend are part of the aforementioned prototype and are part of the submission. as Implementation status: completed.

3) Intelligent scheduling of Shares using Filter Scheduler and Multi-backend support

Allowing one Manila node to manage multiple share backends. A backend can run either or both of share and volume services. Support for shares in filter scheduler allows the cloud administrator to manage large-scale share storage by filtering backends based on predefined parameters.

Implementation status: completed.

4) End to End Experience (Automated Mounting)

A proposal for handling injection / updates of mounts to instantiated guests operating in the Nova context. A listener / agent that could either be interacted directly or more likely poll or receive updates from instance metadata changes would represent one possible solution. The possible use of either cloud-init or VirtFS (which would attach shared file systems to instances in a manner similar to Cinder block storage) is also under consideration.

Additional discussion here: Manila Storage Integration Patterns

Implementation status: Scoping.

5) The last mile problem

Accommodation for a variety of use cases / networking topologies (ranging from flat networks, to Neutron SDNs, to hypervisor mediated options) for connecting from shares to instances are discussed here: Manila Networking

Implementation status: not started.

6) Tenant and Administrative UI

Manila must expose both administrative and tenant Horizon interfaces.

Implementation status: in design phase... the initial Horizon UI will borrow heavily from the existing Cinder tenant facing and administrative UI.


Sub Pages