Manila/Incubation Application

项目代号

Manila

商标

我们不清楚该名称是否存在任何商标冲突。菲律宾的首都名为马尼拉，使其成为专有名词。该项目没有使用任何存在商标问题的其他名称。

概要（项目的一句话摘要）

Manila 项目提供了一个用于管理共享文件系统的 API，支持多种协议和后端实现。

父项目名称和 PTL

项目：共享文件系统

PTL：Ben Swartzlander

使命宣言

简单来说，Manila 项目的目标是为共享文件系统存储做 Cinder 为块存储所做的事情。

我们旨在提供一个供应商中立的管理接口，用于配置和附加共享文件系统，例如 NFS、CIFS 等。在尽可能的情况下，我们旨在镜像 Cinder 的架构，支持公共 REST API、多个后端和执行资源分配决策的调度器。当不可避免地存在差异时，我们计划设计与 OpenStack 的模块化和可扩展性理念兼容的解决方案。

详细描述

Manila 的基本假设是，共享文件系统提供了一些无法从块存储或对象存储获得的宝贵功能，并且 OpenStack 缺少对这种第三种存储形式的管理功能。共享文件系统提供的独特功能是多个实例同时对持久数据进行共享、细粒度、读写访问。NFS 和 CIFS 协议已被开发出来以提供这些功能，并且在使用了数十年后仍然很受欢迎。

Manila 的实现实际上是 Cinder 项目的一个修改后的分支。管理共享文件系统的概念最初是在 2012 年 4 月的 SF 设计峰会上作为 Cinder 的扩展提出，其理论是实现之间将有很多共同代码，并且许多相同的开发人员将对这两个项目感兴趣。由于这个原因，现在 Manila 的初始实现实际上是 2012 年 8 月提交给 Cinder 项目的一个大型补丁。由于各种原因，我们最终决定单独的项目是提供功能的更好方法，Manila 项目由此诞生。

Manila 包含 Cinder 中的所有代码，以及我们添加的共享文件系统管理代码，并删除了所有与块相关的代码。API 在很大程度上镜像现有的 Cinder API，除了“卷”已重命名为“共享”，并且附加过程略有不同。

项目基本路线图

Manila 的初始实现是一个概念验证，证明了共享文件系统管理可以适应与 Cinder 相同的架构。然而，块和共享文件系统之间的主要区别在于存储系统和最终用户如何与存储系统通信。特别是，当实例能够通过网络直接与存储后端通信，并且存储后端能够在保持租户之间安全隔离的同时为多个租户提供服务时，共享文件系统效果最佳。块存储可以简单地通过超visor 虚拟化，后端存储系统要求更少。由于这些差异，需要额外的工作来帮助自动化将共享文件系统附加到租户网络中的一个或多个实例的网络部分，并自动化在 NAS 环境中存在但 SAN 环境中不存在的安全域和其他功能的设置。

在 Icehouse 期间，Manila 团队实现了完整的多租户，以便支持安全多租户的存储控制器驱动程序能够自动在多租户配置中创建存储服务器的虚拟实例。添加了一个“通用”驱动程序，通过在 Nova 和 Cinder 之上分层来实现这种形式的安全多租户。无法本机支持安全多租户的硬件驱动程序仍然允许以单租户模式存在。

在 Juno 期间，团队的重点是扩展驱动程序支持，并创建一个机制来提供基于网关的安全多租户，这会将通用驱动程序提供的安全多租户添加到仅支持单租户模式的后端存储。

项目源代码位置

• 项目代码：https://github.com/stackforge/manila
• Python 客户端：https://github.com/stackforge/python-manilaclient

编程语言、所需技术依赖

语言

Python

依赖项

消息队列、数据库服务器、keystone、neutron 可选的 Manila 部分依赖于：nova、cinder

计划在未来使 neutron 依赖项变为可选。

项目目前是否开源？使用什么许可证？

是 - 采用 Apache 许可证 2.0 版

软件和团队的成熟度

软件

除了从 Cinder 继承的代码外，新的 Manila 代码的历史只有一年多，并且从那时到现在一直积极开发，主要由 NetApp 和 Mirantis 的开发人员进行。

团队

核心团队现在由 NetApp、Mirantis、EMC 和 SUSE 的开发人员组成，自 2013 年 8 月代码开源以来，社区兴趣浓厚。

项目开发者资质

Ben Swartzlander

NetApp - 软件架构师，Manila - PTL

Ben Swartzlander 一直是该项目的技术负责人，从其构思之初到现在已经 2 年，并计划继续从设计和管理方面领导该项目。Ben 在存储行业担任软件工程师超过 13 年，并且在存储系统、网络协议、虚拟化和开源项目方面拥有丰富的经验。Ben 一直是 OpenStack 项目的贡献者近 3 年。

Yulia Portnova

Mirantis - 软件开发人员，Manila - 核心团队

Yulia 自 Essex 版本以来一直在 Mirantis 中使用 OpenStack。对 Nova、Glance、Cinder 有贡献。

Valeriy Ponomaryov

Mirantis - QA 自动化工程师，Manila - 核心团队

Valeriy 自 Folsom 版本以来一直在使用 OpenStack，除了 Manila 项目外，他对 Tempest、CI Config 和 Oslo-Incubator 有贡献，他还开发了 Manila 项目的 Horizon 修改和 Devstack 插件。

Xing Yang

EMC - 顾问技术专家，Manila - 核心团队

Xing 是 EMC 首席技术官办公室的技术专家。她拥有多年与存储技术、数据保护和灾难恢复以及云和虚拟化相关项目合作的经验。Xing 自 Grizzly 版本以来一直是 OpenStack 的贡献者，并在 Cinder 和 Nova 中做出了贡献。

Thomas Bechtold

SUSE - 软件开发人员，Manila - 核心团队

Thomas 自 Grizzly 版本以来一直在使用 OpenStack，并为许多不同的 OpenStack 项目做出了贡献。

Alex Meade

NetApp - 软件开发人员

Alex 在 OpenStack 上工作了 3 年多，是 Glance 项目的核心贡献者。他之前曾在 Rackspace 公有云部署中工作，并对大规模的 OpenStack 感兴趣。

Rushil Chugh

NetApp - 软件开发人员

Rushil 拥有计算机网络硕士学位，自 Grizzly 版本以来一直在使用 OpenStack。Rushil 对企业网络部署、数据存储和虚拟化有浓厚的兴趣。

Clinton Knight

NetApp - 资深软件开发人员

Clinton 拥有电气和计算机工程博士学位，在存储行业工作了 15 年，并且在存储管理和协议以及虚拟化方面拥有丰富的经验。

Dustin Schoenbrun

NetApp - 软件 QA 工程师

Dustin 拥有新罕布什尔大学计算机科学学士学位，在存储行业工作了 8 年，其中 4 年在 NetApp 工作。他曾在 NetApp 与其他供应商的虚拟化产品集成方面担任软件工程师和 QA 工程师，现在专注于 OpenStack 集成。

Rushi Agrawal

Reliance Jio Cloud - 软件开发人员

Andrei Ostapenko

Mirantis - 软件开发人员

Andrei 自 folsom 版本以来一直在使用 OpenStack，并且主要参与新的 stackforge 组件。

Vitaly Kostenko

Mirantis - 软件开发人员

Aleksandr Chirko

Mirantis - 软件开发人员

Vijay Bellur

Red Hat

Csaba Henk

Red Hat

Ramana Raja

Red Hat

Shamail Tahir

EMC

Scott D'Angelo

HP Public Cloud

Deepak C Shetty

Red Hat - OpenStack 开发人员

Julia Varlamova

Mirantis - 实习软件开发人员

Julia 在 OpenStack 上工作了 1.5 年。对 Glance、Cinder、Oslo.DB 有贡献。

Nilesh Bhosale

IBM - 软件开发人员

Nilesh 在 OpenStack 上工作了 1 年。他对 Cinder 有贡献。

ZhongJun

Huawei - 软件开发人员

基础设施需求（测试等）

Manila 不需要超出 devstack、gerrit、jenkins 和 tempest 今天已经提供的任何基础设施。

所有当前贡献者都同意了 OpenStack CLA 吗？

所有当前贡献者均已同意 OpenStack CLA！

附录

Manila 孵化在之前的 TC 会议中被考虑过：[1]

在上次会议中提出的主要反对意见（为便于阅读进行了编辑）：

<ttx> bswartz: I think I can summarize by saying the strongest objection to incubation in last week's discussion was about the maturity of the project
<ttx> Both in terms of number of commits and number of developers involved
<ttx> (We rejected Designate on similar grounds over the last cycle)

Manila 现在“成熟”了 8 个月，团队规模也显著增加。许多新的人正在贡献，并且许多新的人正在致力于贡献。

<ttx> Also seemed like Manila could benefit from another round of discussion regarding its relationship with Cinder

我们在亚特兰大峰会的 Cinder 会议期间讨论了 Manila 和 Cinder 之间的关系。我认为现在没有人对此感到困惑了。对于不熟悉的人来说，可以把 Manila 叠加在 Cinder 之上，也可以把 Cinder 叠加在 Manila 之上，具体取决于您尝试做什么。Cinder 消耗各种类型的后端存储（包括共享文件系统）并提供块存储。Manila 消耗各种类型的后端存储（包括块设备）并提供共享文件系统。这两个项目面临的挑战虽然在技术、公司和参与人员之间存在重叠，但却大不相同。

<jeblair> bswartz: while it is a recent change, devstack, devstack-gate, and tempest are all now modular enough that any stackforge project can do it; wsme and sqlalchemy-migrate are working on that now.
<ttx> bswartz: so it's extremely likely that we'd require you to have gate jobs before being accepted into incubation

我们已经设置了所需的门禁作业。感谢您的帮助。

<lifeless> bswartz: what are the technical hurdles you face?
<bswartz> regarding "technical issues" it's clear that the code we wrote initially only works for single tenant environments -- properly supporting multitenant environments requires a different design
<bswartz> we've been working for the last 3 months on designing that and it's about ready to go in
<lifeless> So incubation is the process of taking a functional project and getting it fully integrated; I am feeling more and more that this is premature.

<markmc> sounds like we're not at the point of architectural stability, though
<zaneb> "The maturity of the project. Has it been used in production and deployed at scale?"
<zaneb> nothing about a stable API specifically
<markmc> bswartz, so e.g. "Technical stability and architecture maturity"
* markmc has to drop off, sorry
<zaneb> but "need to rewrite in order to handle multi-tenant" is hard to reconcile with "mature"

多租户在 Icehouse 周期中实现，我们花了一些时间让尘埃落定。没有进行任何重大更改。最近的所有工作都是改进，而不是重新架构。