暴露存储能力¶
风味（Flavors）允许操作员暴露一些内部存储能力，而无需提供系统配置的详细信息。目前，操作员对暴露给用户的能力拥有完全控制权，无论这些能力是否真正得到保证或有效。一种能力是特定于存储或 Zaqar 的特性——例如，持久性、FIFO、内存中——它们可以基于每个风味启用/暴露，从而允许最终用户为特定队列选择最佳风味。
https://blueprints.launchpad.net/zaqar/+spec/expose-storage-capabilities
问题描述¶
风味在为最终用户提供选择方面非常强大，但操作员无法知道每个存储驱动程序具有哪些能力，这使得此功能完全取决于操作员认为更有意义的内容。
通过明确已部署驱动程序支持哪些功能，通过 API 向操作员提供选择向最终用户暴露哪些功能的支持非常重要。此外，这对于基于服务尝试支持的使用案例进行适当的容量规划也很重要。
提议的变更¶
能力¶
此变更请求建议定义一组内部能力以及存储驱动程序暴露其支持的能力的方式，以便操作员可以提前知道风味将支持什么以及他们可能需要的存储驱动程序。
内部能力集包括
FIFO
AOD（至少一次传递）
高吞吐量
声明
暴露能力¶
如果支持，存储驱动程序应暴露这些能力。此规范建议在基类中添加一个新的类方法，称为capabilities，该方法应返回一个包含支持的能力列表的集合。返回在此集合中的能力不能是自定义的，这意味着它们必须在内部得到支持。
@six.add_metaclass(abc.ABCMeta)
class DataDriverBase(DriverBase):
...
@property
def capabilities(self):
return self._CAPABILITIES
驱动程序加载¶
除了上述更改之外，我们还需要一种更好的方法来基于能力加载驱动程序。也就是说，在加载驱动程序时，有必要将每个风味启用的能力传递给驱动程序，以便驱动程序本身可以针对某些能力进行专门化。在大多数情况下，加载驱动程序最终将导致始终加载相同的实现。但是，在某些情况下——例如 FIFO——根据存储可能需要更专门的实现。因此，与其始终加载DataDriver，此规范建议添加一个新的get_driver函数，该函数将允许存储本身根据传递的能力加载驱动程序。
def get_driver(plane='data', capabilities=None):
...
这意味着我们不需要将DataDriver或ControlDriver注册为`entry_points，而只需注册新的get_driver函数。这将允许存储驱动程序暴露更少的公共 API。上述get_driver提案的一个变体是。
def get_driver(base=base.BaseDataDriver, capabilities=None):
...
这样我们可以避免为这些平面命名，而只需询问我们需要的“签名”即可。但是，这使得加载实际驱动程序变得更加复杂，并且还会跨不同的存储驱动程序复制一些逻辑。
池和风味¶
风味支持能力。目前，这些能力是 100% 自定义的。通过实施此规范，风味可以提前知道基于池中注册的存储支持哪些能力。
但是，池不应允许具有不同能力的存储驱动程序在同一个池中共存。也就是说，池必须在向池添加新节点时验证存储能力，并确保新节点支持的能力与池中其余节点的能力一致。
备选方案¶
保持自定义，不做任何事情。
实现¶
负责人¶
- 主要负责人
flaper87
- 二级分配人
vkmc
里程碑¶
- 完成目标里程碑
K-1
工作项¶
定义内部能力列表并记录它
添加所需的抽象，以暴露存储驱动程序支持的能力
让风味在加载存储驱动程序时将能力传递给它。
依赖项¶
注意
本作品采用知识共享署名 3.0 非移植许可协议授权。 http://creativecommons.org/licenses/by/3.0/legalcode
