服务风味框架

https://blueprints.launchpad.net/neutron/+spec/neutron-flavor-framework

本文档详细说明了一个框架，旨在使操作员能够配置，并允许用户在 Neutron 中选择服务实现的不同的抽象表示。这种表示将逻辑配置与其实例化分离，从而支持多种可能的实现共存。分离还允许操作员根据部署需求创建用户选项。该提案不需要对驱动程序进行任何重大集成即可实现。

问题描述

服务提供商框架允许服务由多个驱动程序支持；但是，当前方法存在一些限制。这些限制包括

  • 操作员无法在用户不知情的情况下修改部署。

  • 操作员无法轻松配置相同驱动程序的不同服务级别。

  • 操作员无法在多厂商环境中透明地部署服务。

  • 操作员无法轻松地将服务重新安排到另一个后端。

  • 操作员无法影响后端选择过程中的调度。

  • 用户必须了解实现服务的驱动程序。

  • 厂商无法区分。

  • 扩展无法轻松通过 REST API 暴露给用户。

提议的变更

提出的解决方案是通过 REST API 暴露两个新的逻辑实体，以将逻辑配置与后端实现分离。第一个实体称为风味（Flavor），是操作员策划的后端实现描述。风味属性包括 id、名称、扩展列表、服务、服务配置文件、选择算法和启用标志。扩展列表用于为与风味关联的逻辑配置启用额外的 REST API 功能。例如，可以为负载均衡启用 TLS 和/或 L7。允许用户查询和查看风味的公共属性。选择算法确定服务配置文件，驱动程序将实例调度到后端。

第二个实体是服务配置文件（Service Profile），具有 id、名称、入口点、驱动程序初始化元数据和启用标志等属性。服务配置文件允许操作员将驱动程序入口点与初始化驱动程序所需的元数据关联起来。元数据的一个好处是，相同的驱动程序可以支持不同的风味定义。可以将多个服务配置文件与相同的风味关联，以支持多厂商/多驱动程序环境。

此扩展将在核心服务器中引入一个新的 RPC 方法。该方法将处理将逻辑实例调度到后端。调度涉及将逻辑配置绑定到具有容量的后端。调度完成后，插件将直接将调用分派到驱动程序。调度方法实现将有意保持简单，以便在周期内完成这项工作。未来的工作可能包括通过集成 Gantt（一个将 Nova 调度程序提供给其他 OpenStack 组件的项目）和/或开发一种方法让后端表达负载/容量来包含更高级的调度程序。

虽然可以将风味和服务配置文件存储在配置文件中，但本文档建议将实体存储在数据库中。存储在关系数据库中可确保在 neutron 服务器和工作进程之间实现原子性和一致性，从而避免配置部署竞争。此外，操作员可以在不停止系统的情况下添加/更新/删除风味。（注意：如果正在使用，则不能更改或删除风味和服务配置文件）。

用户工作流程

用户将查询按服务过滤的已启用风味列表。然后，用户将创建服务的逻辑实体，并传递风味 id。此后的用户工作流程将保持不变。如果选择了具有多个服务配置文件的风味，则通过加权随机算法选择配置文件（如下所示）。

管理员工作流程

了解部署中硬件/软件版本的管理员将创建要提供给用户的风味。操作员将选择风味将支持的扩展，并确保关联适当的服务配置文件。

未来的工作包括特定租户的风味和高级调度（集成到 Gantt 项目和/或过滤器）。

该提案允许厂商差异化，因为风味定义可以包括操作员可以选择启用的厂商 API 扩展。

数据模型影响

将向数据库添加两个新的逻辑模型。

风味

id: uuid name: string description: text service: LOADBALANCER, VPN, FIREWALL, L3_ROUTER, 等 supported_extensions: 逗号分隔的值字符串 selection_algorithm: Enum(random, available, least_used) service_profiles: [(uuid 列表, weight)] (JSON 列表) enabled: boolean

服务配置文件

id: uuid description: text driver: string metainfo: string(json 编码的字典) enabled: boolean

现有的 provider 属性将被更改为 service_profile_id，并用于将服务的逻辑模型的根与配置文件关联起来。

REST API 影响

新的逻辑模型将通过 API 暴露。逻辑模型的 CRUD 操作仅暴露给管理员，但 Flavor 的读取操作除外。所有用户都能够查询并获取单个风味的详细信息，其中包含一组有限的属性（id、名称、描述、服务和服务扩展）。此外，每个服务将添加一个管理操作：reschedule(id)。此操作将使操作员能够强制系统重新调度逻辑服务的后端。

风味 (/flavors)

属性名称

类型

访问

默认值

验证/转换

描述

id

字符串 (UUID)

RO, 全部 RW, admin

生成

N/A

identity

name

string

RO, 全部 RW, admin

‘’

string

人类可读的名称

description

string

RO, 全部 RW, admin

‘’

string

人类可读的描述

服务

string

RO, 全部 RW, admin

‘’

string

token 将风味映射到 svc

service_profiles

list

RO, 全部 RW, admin

[]

json 列表

驱动程序映射和权重

supported_extensions

string

RO, 全部 RW, admin

‘’

string

可用的 api 扩展

selection_algorithm

enum

RO, 全部 RW, admin

random

参见模型

如何选择配置文件

enabled

bool

RO, 全部 RW, admin

true

bool

切换

服务配置文件 (/service_profiles)

属性名称

类型

访问

默认值

验证/转换

描述

id

字符串 (UUID)

RO, 全部 RW, admin

生成

N/A

identity

description

string

RO, 全部 RW, admin

‘’

string

人类可读的描述

driver

string

RO, 全部 RW, admin

‘’

string

python 模块路径到驱动程序

metainfo

string

RO, 全部 RW, admin

‘’

json 字符串

元数据

enabled

bool

RO, 全部 RW, admin

true

bool

切换

安全影响

policy.json 将更新为允许所有用户查询风味列表并请求有关特定风味条目的详细信息。REST 点的创建/更新/删除操作除外，这些操作仅限管理员。此外，服务配置文件的 CRUD 操作将限制为管理员。

通知影响

当前通知的内容将发生微小变化，以添加一个新的风味属性。该属性将用于诸如计费之类的应用程序，并且可以被 Ceilometer 捕获。provider 属性将保留给希望跟踪用户风味和后端的运营商。

其他最终用户影响

N/A

性能影响

当逻辑表示被调度到实际后端时，会产生最小的开销。选择后端后，将通过驱动程序调用直接进行通信。

IPv6 影响

无

其他部署者影响

部署者需要创建他们希望向用户公开的风味配置。在迁移期间，现有的 provider 配置将被转换为基本的风味类型。迁移完成后，部署者将有机会修改风味定义。

开发人员影响

预期的开发人员影响应该最小，因为该框架仅影响逻辑服务到后端的初始调度。驱动程序实现应保持不变，除非添加容量调用。

社区影响

该提案允许操作员提供超出直接实现的服务，并且以不会增加社区维护或负担的方式进行。

备选方案

继续什么都不做。

实现

负责人

Doug Wiegley（原始规范和代码由 markmcclain 和 enikanorov 提供）

工作项

  • 实现新的模型

  • 实现 REST API 扩展（包括测试）

  • 实现调度 RPC 调用。

  • 为 LBaaS、VPNaaS 和 FWaaS API 添加对风味的支持。

  • 现有部署的实施迁移脚本。

  • 确保 Ceilometer 的通知可用。

  • 添加客户端 API 支持

依赖项

不依赖于其他工作。值得注意的是，许多其他项目依赖于风味。

测试

Tempest 测试

Tempest 测试，包括新的 API 和场景测试，以验证新的实体。

功能测试

由于此 API 不直接更改数据路径，因此将排除功能测试。 （更改数据路径的元素由其他功能测试涵盖）。

API 测试

将测试新的 API。

文档影响

用户文档

需要包含用户文档，以描述用户在使用风味构建逻辑拓扑时如何使用风味。需要创建操作员文档，以详细说明如何管理风味和服务配置文件。

开发人员文档

此外，新的 REST 端点的文档需要包含在网络 API 描述中。

参考资料