Jump to: navigation, search

Difference between revisions of "Manila/Program Application"

(Development Team)
 
(11 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
== Official Title ==
 
== Official Title ==
Shared Filesystems
+
Shared File Systems
  
 
== Mission Statement ==
 
== Mission Statement ==
The goal of the Shared Filesystems program is to provide a set of services for management of shared filesystems in a multitenant cloud environment, similar to how OpenStack provices for block-based storage management through the Block Storage program.
+
The goal of the Shared File Systems program is to provide a set of services for management of shared file systems in a multitenant cloud environment, similar to how OpenStack provides for block-based storage management through the Block Storage program.
  
We aim to provide a vendor neutral management interface that allows for provisioning and attaching shared filesystems such as NFS, CIFS, and more. To the extent possible we aim to mirror the architecture of Block Storage program, with support for a public REST API, multiple backends, and a scheduler that performs resource assignment decisions. When differences are unavoidable, we plan to design solutions that are compatible with the OpenStack ideals of modularity and scalability.  
+
We aim to provide a vendor neutral management interface that allows for provisioning and attaching shared file systems such as NFS, CIFS, and more. To the extent possible we aim to mirror the architecture of Block Storage program, with support for a public REST API, multiple backends, and a scheduler that performs resource assignment decisions. When differences are unavoidable, we plan to design solutions that are compatible with the OpenStack ideals of modularity and scalability.
  
 
== Deliverables ==
 
== Deliverables ==
* A set of services (API server, scheduler, and share manager) that provide an infrastructure for self-sevice provisioning and managing shared filesystems in a multitenant cloud
+
* A set of services (API server, scheduler, and share manager) that provide an infrastructure for self-sevice provisioning and managing shared file systems in a multi-tenant cloud
 
* A CLI-based client for users and administrators to interact with the API
 
* A CLI-based client for users and administrators to interact with the API
 
* A Horizon GUI plugin
 
* A Horizon GUI plugin
* A "generic" sorfware-only driver that runs on any hardware, allowing people to use the service without specialized equipment
+
* A "generic" software-only driver that runs on any hardware, allowing people to use the service without specialized equipment
 
* An example image (cirros-based) that implements part of the "generic" storage service, with documentation on how admins can create their own
 
* An example image (cirros-based) that implements part of the "generic" storage service, with documentation on how admins can create their own
 
* A set of drivers for commercial NAS storage servers
 
* A set of drivers for commercial NAS storage servers
Line 21: Line 21:
  
 
== ATC Status ==
 
== ATC Status ==
The program grants Active Technical Contributor (ATC) status to anyone completing a commit to any program repository during the previous two release cycles. Core project team members may grant ATC to significant, non code contributors for two cycles.
+
The program grants Active Technical Contributor (ATC) status to anyone completing a commit to any program repository during the previous two release cycles. Core project team members may grant ATC to significant, non code-contributors for two cycles.
  
 
== Development Team ==
 
== Development Team ==
PTLː Ben Swartzlander
+
====PTLː====
 +
* Ben Swartzlander
  
 
====The core teamː====
 
====The core teamː====
 
* Yulia Portnova
 
* Yulia Portnova
 
* Valeriy Ponomaryov
 
* Valeriy Ponomaryov
* Xing Yang (pending team vote)
+
* Xing Yang
  
 
====Significant contributorsː====
 
====Significant contributorsː====
Line 35: Line 36:
 
* Rushil Chugh
 
* Rushil Chugh
 
* Clinton Knight
 
* Clinton Knight
* Xing Yang
 
 
* Vitaly Kostenko
 
* Vitaly Kostenko
 
* Andrei Ostapenko
 
* Andrei Ostapenko
 
* Aleksandr Chirko
 
* Aleksandr Chirko
* Ramama Raja
+
* Csaba Henk
 +
* Ramana Raja
 
* Christian Berendt
 
* Christian Berendt
  
Line 45: Line 46:
 
We started a new program for two main reasons:
 
We started a new program for two main reasons:
 
* Initially we tried to address the above needs by expanding the scope of the Block Storage program, but the Cinder core team didn't want the additional responsibility. This left us with no option other than to start a new program.
 
* Initially we tried to address the above needs by expanding the scope of the Block Storage program, but the Cinder core team didn't want the additional responsibility. This left us with no option other than to start a new program.
* While there is significantly overlap between Block Storage and Shared Filesystems, the differences are large enough to require a dedicated group of developers to solve the unique problems related to Shared Filesystems. Keeping the programs separate has been greatly advantageous as it allows each group to focus on different problems and ultimately get more done.
+
* While there is some overlap between Block Storage and Shared File Systems, the technical implementation details and use cases are substantial enough to require a dedicated group of developers to solve the unique problems related to Shared File Systems. Keeping the programs separate has been greatly advantageous as it allows each group to focus on different problems and ultimately get more done.
 +
<br />
 +
'''NOTE''': Manila started as a fork of Cinder given that it provides facility for many of the concepts that a Shared File Systems 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.  Manila is thus based on an evolution of Cinder. Manila, however, addresses a variety of additional concerns that aren't relevant to Cinder operation (e.g. provisioning into tenant SDN, mapping to auth authority / user namespace, et cetera). After involved 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 remaining commonality between Cinder and the File Share Service into Oslo over time where sensible.

Latest revision as of 16:08, 7 August 2014

Official Title

Shared File Systems

Mission Statement

The goal of the Shared File Systems program is to provide a set of services for management of shared file systems in a multitenant cloud environment, similar to how OpenStack provides for block-based storage management through the Block Storage program.

We aim to provide a vendor neutral management interface that allows for provisioning and attaching shared file systems such as NFS, CIFS, and more. To the extent possible we aim to mirror the architecture of Block Storage program, with support for a public REST API, multiple backends, and a scheduler that performs resource assignment decisions. When differences are unavoidable, we plan to design solutions that are compatible with the OpenStack ideals of modularity and scalability.

Deliverables

  • A set of services (API server, scheduler, and share manager) that provide an infrastructure for self-sevice provisioning and managing shared file systems in a multi-tenant cloud
  • A CLI-based client for users and administrators to interact with the API
  • A Horizon GUI plugin
  • A "generic" software-only driver that runs on any hardware, allowing people to use the service without specialized equipment
  • An example image (cirros-based) that implements part of the "generic" storage service, with documentation on how admins can create their own
  • A set of drivers for commercial NAS storage servers
  • API documentation, Administrator documentation, and Developer documentation

Repositories

ATC Status

The program grants Active Technical Contributor (ATC) status to anyone completing a commit to any program repository during the previous two release cycles. Core project team members may grant ATC to significant, non code-contributors for two cycles.

Development Team

PTLː

  • Ben Swartzlander

The core teamː

  • Yulia Portnova
  • Valeriy Ponomaryov
  • Xing Yang

Significant contributorsː

  • Alex Meade
  • Rushil Chugh
  • Clinton Knight
  • Vitaly Kostenko
  • Andrei Ostapenko
  • Aleksandr Chirko
  • Csaba Henk
  • Ramana Raja
  • Christian Berendt

Why a new program?

We started a new program for two main reasons:

  • Initially we tried to address the above needs by expanding the scope of the Block Storage program, but the Cinder core team didn't want the additional responsibility. This left us with no option other than to start a new program.
  • While there is some overlap between Block Storage and Shared File Systems, the technical implementation details and use cases are substantial enough to require a dedicated group of developers to solve the unique problems related to Shared File Systems. Keeping the programs separate has been greatly advantageous as it allows each group to focus on different problems and ultimately get more done.


NOTE: Manila started as a fork of Cinder given that it provides facility for many of the concepts that a Shared File Systems 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. Manila is thus based on an evolution of Cinder. Manila, however, addresses a variety of additional concerns that aren't relevant to Cinder operation (e.g. provisioning into tenant SDN, mapping to auth authority / user namespace, et cetera). After involved 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 remaining commonality between Cinder and the File Share Service into Oslo over time where sensible.