风味框架 - 模板和元数据¶
https://blueprints.launchpad.net/neutron/+spec/neutron-flavor-framework-templates
风味框架规范引入了一个静态框架，用于为服务创建不同的功能级别。本提案增加了被服务创建的对象影响风味行为的能力。
问题描述¶
原始的风味框架允许操作员为给定的服务创建自定义功能级别。但是，某些功能需要基于实例的数据才能有效地部署。
例如，一个提供页面缓存的负载均衡器。使用风味，您可以指定一个没有页面缓存的风味，另一个指定缓存所有页面。但是，完全页面缓存通常会破坏遗留应用程序，并且某些 URL 通常需要被排除在外，具体取决于每个负载均衡器，例如“进行页面缓存，但不针对 /legacy/bank/thingie”。
另一个例子是操作员选择为特定级别的负载均衡器启用 DDoS 保护，但像这些安全功能通常需要为最终管理员提供一个基于实例的白名单，以便能够快速处理误报。
提议的变更¶
本提案建议对现有的风味框架进行两项更改
添加一个“风味对象元数据”的模型/表，该元数据存储于任何给定的风味启用 neutron 对象，并与该对象的 UUID 反向引用，以及一个混入（/me 隐藏）将“flavor_meta”属性添加到所述对象。
在传递给驱动程序中的“metadata”字段中，支持 jinja 模板语法，并提供宏替换功能，用于 neutron 模型属性或上述基于实例的元数据。宏替换将在生成的“metadata”传递给后端插件/驱动程序之前发生，因此驱动程序不需要了解此模板。
这旨在作为操作员使用的临时机制，以启用 OpenStack 中其他缺失的某些功能，而无需直接修改 neutron。
示例
使用静态风味框架，您可能有一个名为“AwesomeSauce”的风味，其中包含负载均衡和 DDoS 保护，驱动程序元数据可能如下所示
{
vendor_z23_ddos_protection: true
}
这正是将传递给 z23 lbaas 驱动程序的内容。使用模板语法，该示例变为
{
vendor_z23_ddos_protection: true
z23_funky_whitelist: [ {{ meta.whitelist }} ]
}
与 LoadBalancer 对象上对应的 flavor_meta 字段为
{
whitelist: "1.2.3.4, 8.8.8.8"
}
并将传递给驱动程序的最终元数据为
{
vendor_z23_ddos_protection: true
z23_funky_whitelist: [ '1.2.3.4', '8.8.8.8' ]
}
数据模型影响¶
将向数据库添加一个新的逻辑模型。
FlavorMeta
id: uuid
object_id: uuid
key: string
value: string
ServiceProfile 模型将被修改，以添加一个“allowed_meta_keys”属性，该属性与可以在“metadata”属性中定义的模板结合使用，定义了最终用户可以作为 flavor_meta 数据提交的允许的附加数据。
以下现有模型将被修改，并添加一个“meta”方法，该方法将查找关联的 FlavorMeta 数据
LoadBalancer
随着越来越多的功能变得风味感知，它们的根模型应该添加 meta 方法（混入？）。
REST API 影响¶
支持风味启用的模型将添加一个 flavor_meta 属性。设置此属性将创建一个关联的 FlavorMeta 模型。
属性名称 |
类型 |
访问 |
默认值 |
验证/转换 |
描述 |
|---|---|---|---|---|---|
flavor_meta |
list |
RW，全部 |
‘’ |
键/值列表 |
基于对象的元数据 |
资源：/service_profile
属性名称 |
类型 |
访问 |
默认值 |
验证/转换 |
描述 |
|---|---|---|---|---|---|
allowed_meta_keys |
list |
RW，管理员 |
‘’ |
list |
flavor_meta 的键 |
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
这是操作员启用的一种附加钩子。如果存在，用户可以通过 API 与 flavor_meta 属性进行交互。
性能影响¶
无
IPv6 影响¶
无
其他部署者影响¶
无
开发人员影响¶
希望支持风味和此模板机制的服务/模型需要添加适当的模型条目和数据库迁移。
社区影响¶
此更改允许操作员在 Neutron 框架内更灵活地启用高级服务。
可以通过此机制启用的许多功能可以并且应该作为其相应服务项目的特性添加。本提案指定了一种机制，供操作员和供应商启用那些由于某种原因尚未由 OpenStack 开发社区解决的功能。这可能是因为该功能过于小众而无法广泛应用，发布时间线太远，或者根本不存在一个好的开源替代方案。本提案增加了一种机制来处理过渡期，直到主流功能得到支持。
最佳实践
如果您需要迁移风味，之前的决定是，如果您必须使用新的风味创建一个新的服务实体。目前无法修改它们。这适用于所有风味，而不仅仅是本提案。
如果存在等效的社区功能，鼓励操作员使用该功能/提供反馈/贡献。驱动程序的推荐最佳实践是，主线中公开的功能优先于通过 flavor meta-data 公开的功能
显而易见的是，启用由单个供应商提供的功能对操作员来说有两件事：1. 它允许操作员利用该功能并将其暴露给他们的用户。 2. 如果用户使用该功能，操作员将来选择更换供应商可能会更加困难。此外，对于由多个供应商提供的功能，如果操作员希望支持多个供应商，则必须小心地抽象这些功能。
备选方案¶
第一种替代方案是什么都不做。这将导致许多供应商今天所做的事情，即为了暴露更高级的功能而创建专有的 neutron 解决方案。这会导致操作员的不一致解决方案、跟踪 trunk 的难度增加以及供应商锁定。
另一种替代方案是与本提案相同，但删除了风味元数据上的模板。由于风味元数据与特定的驱动程序（因此是供应商特定的）相关联，因此删除模板将迫使供应商将其供应商特定的内容暴露给最终用户。此外，由于可以使用多个服务配置文件（驱动程序/供应商）来实现单个风味，因此没有模板意味着除非这些后端支持完全相同的后端元数据，否则多个后端支持将中断，这不太可能且不切实际。
最后，最直接的替代方案是将每个功能本机实现到服务 API 中。在上述页面缓存示例中，将页面缓存作为 API 中的一个功能添加，并带有 URL 异常列表，并等待所有驱动程序实现该后端。这会增加整个社区的维护和开发负担，并且意味着 Neutron 在添加市场中出现的新功能方面将存在内置滞后。
实现¶
负责人¶
工作项¶
添加新的数据模型和迁移。
为 neutron 模型添加混入，并带有“meta”方法。
将混入添加到 LoadBalancer，及其 REST 属性。
修改风味以将 jinja 模板应用于服务配置文件元数据属性。
依赖项¶
主风味框架
LBaaS v2
测试¶
Tempest 测试¶
需要增强风味测试，以包括基于对象的元数据和一些基本的模板化风味元数据，并验证替换后的数据是否传递给后端。
功能测试¶
测试以验证模型中的 flavor_meta 字段，以及在传递给后端之前，风味代码中是否正确发生 jinja 替换。
API 测试¶
修改风味 API 测试，以包含对象的 flavor_meta 字段。
文档影响¶
用户文档¶
此更改对最终用户不可见。
开发人员文档¶
部署者需要有关新 API 字段和模板语法的文档。
