增强 VNF 生命周期管理中的多租户策略¶
https://blueprints.launchpad.net/tacker/+spec/enhance-multi-tenant-policy
本文档讨论了 VNF 生命周期管理中多租户策略的增强。
讨论如何使非管理员角色用户能够实例化 VNF，以及管理员角色用户和非管理员角色用户之间的租户隔离。
问题描述¶
在 tacker 中，非管理员角色用户可以获取 VNF 的资源信息，但无法执行某些 VNF LCM 操作，例如 VNF 实例化。
其次，需要实现 VNF LCM 操作的负面功能测试用例，并验证订阅序列中指定的租户是否收到通知。
提议的变更¶
1. 允许非管理员角色用户实例化 VNF¶
在 OpenStack Heat 编排模板 (HOT) 中，可以创建大多数 OpenStack 资源类型，例如实例、浮动 IP 地址、卷、安全组和用户，这些统称为堆栈创建过程。
注意
默认情况下，管理员角色用户允许创建 OpenStack 堆栈。
为了允许非管理员角色用户创建 VNF，必须更改 OpenStack 资源策略。
以下提及的策略需要进行更改
Heat 策略
resource_types:OS::Nova::Flavor
resource_types:OS::Cinder::VolumeType
resource_types:OS::Neutron::QoSPolicy
resource_types:OS::Neutron::QoSBandwidthLimitRule
Nova 策略
os_compute_api:os-flavor-manage
os_compute_api:os-flavor-manage:create
os_compute_api:os-flavor-manage:delete
Neutron 策略
create_policy
create_policy_bandwidth_limit_rule
注意
根据调查，OpenStack 允许管理员角色用户创建堆栈，创建过程涉及不同的 OpenStack 服务（例如 Heat、Nova、Glance 等）。
为了使非管理员角色用户能够使用，需要上述策略更改以及所需 OpenStack 服务中的代码级别更改。
本周期暂缓调查，未来可以恢复。
2. 负面功能测试用例设计¶
如 spec [1] 中所述的多租户环境功能测试案例架构，为每个租户专门分配一个订阅通知服务器。验证这些服务器仅接收其各自租户执行的 VNF 包或 LCM 操作的警报。
为了满足设计要求，为每个租户创建了多个假 HTTP 服务器实例，用作通知服务器。在 Zuul 中，假 HTTP 服务器类实例在同一测试节点（controller-tacker）上运行。在单租户环境中，所需的 HTTP 请求和响应在功能测试用例中被模拟（mock）。 类似地，在多租户环境中，对通知服务器进行模拟 HTTP 请求和响应，并额外验证通知中存在的租户详细信息。
备选方案¶
在 Zuul 中设计负面功能测试用例的另一种方法是需要两个不同的节点来构建通知服务器。
这种方法具有以下设计/实现挑战
添加两个新的 Zuul 节点，并打开一个特定的端口（在 Zuul 中打开端口可能需要特殊请求）。
在新节点上，使用 ansible-playbook 或类似工具设置 HTTP 服务器。
网络问题可能导致实际 HTTP 请求超时。
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
无
其他部署者影响¶
无
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
Manpreet Kaur <kaurmanpreet2620@gmail.com>
工作项¶
识别并启用允许非管理员角色用户创建 VNF 的 OpenStack 策略。
添加 VNF LCM 操作的负面功能测试用例，并验证订阅序列中指定的租户是否收到通知。
依赖项¶
无
测试¶
将添加功能测试以涵盖 spec 中所需的案例。
文档影响¶
无
