Neutron/FlavorFramework
原理
Flavor Framework 的目的是提供一个 API，允许用户通过一组已声明的服务能力来选择服务类型，而不是通过提供商类型或命名供应商来选择。
Flavor 面向用户的部分是一组服务参数。 提出的 Flavor 概念类似于 nova 的概念，区别在于 Flavor 参数是动态的（例如，不是固定的或硬编码的）。
从实现的角度来看，Flavor 是一个用于将逻辑服务实例（对于任何服务）绑定到具体提供商的对象，该提供商随后将被用于在通过持久层后分派 REST API 调用。
绑定过程称为调度；它将为特定资源（在创建时）选择的 Flavor 映射到提供商，然后映射到特定的后端。
对象模型
Flavor Framework 定义了以下对象
Flavor
属性
* Service Type - string identifier (LOADBALANCER, FWAAS, L3, VPN, etc) * Name - name of the flavor * Tags - string containing a list of (key, value) pairs (tags) that define capabilities.
每个驱动程序，包括每个服务的默认驱动程序，都应提供至少其默认能力对象。
API
公共 API 包括 flavors 资源，用户可以列出或显示该资源
neutron flavor-list ------------------------------------------------------------------------------ | ID | Service Type | Name | Description | ------------------------------------------------------------------------------ | UUID | LOADBALANCER | Reference | Basic LB | | UUID | LOADBALANCER | Hi-perf | expensive | ------------------------------------------------------------------------------
neutron flavor-show UUID --------------------------------------------------------- | ID | UUID | | Service Type | VPN | | Name | ipsec | | Description | reference | | Tags | [Tags] | ---------------------------------------------------------
只有管理员才能使用 create/update/delete 命令。
服务资源（代表服务实例，如 vpn 连接、防火墙、池或 vip、路由器）获得公共属性 'flavor'，该属性可以在创建时指定。
调度
调度是为资源选择提供商和后端的流程。 有一些问题需要讨论
- 调度应该是一个单步过程吗？ 例如，提供商和后端都应该是调度的结果吗？
似乎是的：如果我们推迟将资源绑定到后端，我们可能会成功调度到提供商，但无法成功调度到后端，因此资源将处于 ERROR 状态，并且需要重新调度到不同的 Flavor。
尽早失败更好。
- 调度应该从 (provider, backend) 列表中选择，还是先选择提供商，然后提供商选择后端？
似乎第二种方法更简单，因为它不会对后端调度施加设计限制。
例如，后端可以是代理或设备，我们不需要为它们设计用于单个调度器的数据结构。
工作流程
TDB
- Flavor Framework 应该允许简单的无提供商资源创建
如果未指定 Flavor，则新资源将调度到某个服务的默认提供商。
驱动程序要求
迁移
预计从现有配置的迁移将是直接的。
如果服务支持 Provider Framework，则其服务实例对象具有 'provider' 属性，该属性有助于将 REST API 调用分派到正确的驱动程序。
从 Flavor Framework 的角度来看，这些资源似乎已经使用未知的 Flavor 进行了调度。
这不应影响它们的可操作性和管理状态。
从 REST API 的角度来看，'provider' 属性仅对管理员可见（并且不能在 create/update 中提供），而 Flavor 属性可用于常规用户的 create/update 操作。
