支持 v2 LCM API 中的 CNF 回滚¶
https://blueprints.launchpad.net/tacker/+spec/support-nfv-solv3-error-handling
本规范增强了 v2 版本的回滚 API，以支持 CNF。
问题描述¶
Yoga 版本支持 ETSI NFV SOL002 v3.3.1 [1] 和 SOL003 v3.3.1 [2] 中定义的 VNF 生命周期管理 (LCM) 操作。它还支持使用 v2 API（例如实例化 API、终止 API 和更改当前 VNF 包 API）进行 CNF 生命周期管理。
然而，v2 回滚 API 尚未完全支持 CNF LCM。在 v2 LCM API 中支持 CNF 使 Tacker 成为更强大的通用 VNFM。
提议的变更¶
本规范增强了以下 API 以支持 CNF。
回滚 VNF 任务 (POST /vnf_lcm_op_occs/{vnfLcmOpOccId}/rollback)
Yoga 版本已经支持了针对变更当前 VNF 包的回滚 v2。此外，v2 LCM API 已经支持了 CNF 的修改 VNF 信息，因为这与 VNF 的通用处理方式相同。因此，本规范建议支持以下 API 的 v2 CNF 回滚：
实例化 VNF
扩展 VNF
注意
由于相关的标准规范尚未由 ETSI NFV 定义，因此 CNF 的更改外部 VNF 连接及其回滚不受支持。
实例化回滚¶
除了 InfraDriver（KubernetesDriver）处理之外，当前实现没有变化。
该过程包括以下步骤，如图所示
先决条件：VNF 生命周期管理操作实例处于“FAILED_TEMP”状态。
客户端向“回滚操作”资源发送一个空的 POST 请求。
VNFM 向端点（例如客户端）发送带有“ROLLING_BACK”状态的 VNF 生命周期管理操作实例通知，以指示生命周期管理操作的处理过程。
VNFM 向 Kubernetes 发送 Read 请求以检查资源是否存在。
如果资源是由失败的实例化操作创建的，VNFM 向 Kubernetes 发送 Delete 请求以删除这些资源。
VNFM 向 Kubernetes 发送 Read 请求以检查资源是否已被删除。
在成功回滚后，VNFM 向端点（例如客户端）发送带有“ROLLED_BACK”状态的 VNF 生命周期管理操作实例通知，以指示操作已成功完成。
在回滚失败后，VNFM 向端点（例如客户端）发送带有“FAILED_TEMP”状态的 VNF 生命周期管理操作实例通知，以指示操作的中间错误（回滚失败）。
后置条件：VNF 生命周期管理操作实例处于以下状态之一：“FAILED_TEMP”、“ROLLED_BACK”。
KubernetesDriver 调用以下 API 以删除资源并检查其状态：
API 组 |
类型 |
API 方法 |
|---|---|---|
ApiregistrationV1Api |
读取 |
read_<kind> |
删除 |
delete_<kind> |
|
AppsV1Api |
读取 |
read_namespaced_<kind> |
删除 |
delete_namespaced_<kind> |
|
AutoscalingV1Api |
读取 |
read_namespaced_<kind> |
删除 |
delete_namespaced_<kind> |
|
BatchV1Api |
读取 |
read_namespaced_<kind> |
删除 |
delete_namespaced_<kind> |
|
CoordinationV1Api |
读取 |
read_namespaced_<kind> |
删除 |
delete_namespaced_<kind> |
|
CoreV1Api |
读取 |
read_namespaced_<kind> |
删除 |
delete_namespaced_<kind> |
|
读取 |
read_<kind> |
|
删除 |
delete_<kind> |
|
NetworkingV1Api |
读取 |
read_namespaced_<kind> |
删除 |
delete_namespaced_<kind> |
|
RbacAuthorizationV1Api |
读取 |
read_namespaced_<kind> |
删除 |
delete_namespaced_<kind> |
|
读取 |
read_<kind> |
|
删除 |
delete_<kind> |
|
SchedulingV1Api |
读取 |
read_<kind> |
删除 |
delete_<kind> |
|
StorageV1Api |
读取 |
read_<kind> |
删除 |
delete_<kind> |
Read API 的参数是 name。此外，某些 API 还需要 namespace。
Delete API 的参数是 name 和 body。此外，某些 API 还需要 namespace。在回滚操作的情况下，body 不进行设置。
扩展回滚¶
除了 InfraDriver 处理之外，当前实现没有变化。
该过程包括以下步骤，如图所示
先决条件：VNF 生命周期管理操作实例处于“FAILED_TEMP”状态。
客户端向“回滚操作”资源发送一个空的 POST 请求。
VNFM 向端点（例如客户端）发送带有“ROLLING_BACK”状态的 VNF 生命周期管理操作实例通知，以指示生命周期管理操作的处理过程。
VNFM 向 Kubernetes 发送 Read 请求以检查资源的副本数。
如果副本数已被失败的扩展操作更新，VNFM 向 Kubernetes 发送 Update 请求以将副本数更新为扩展之前的数量。
VNFM 向 Kubernetes 发送 Read 请求以检查资源是否已被删除。
在成功回滚后，VNFM 向端点（例如客户端）发送带有“ROLLED_BACK”状态的 VNF 生命周期管理操作实例通知，以指示操作已成功完成。
在回滚失败后，VNFM 向端点（例如客户端）发送带有“FAILED_TEMP”状态的 VNF 生命周期管理操作实例通知，以指示操作的中间错误（回滚失败）。
后置条件：VNF 生命周期管理操作实例处于以下状态之一：“FAILED_TEMP”、“ROLLED_BACK”。
注意
使用 OpenStack VIM 进行扩展的 v2 VNF 回滚会删除扩展操作添加的资源。但是，使用 Kubernetes VIM 进行扩展的 v2 CNF 回滚无法指定删除的 VNFC，因为 Kubernetes 的功能无法控制删除的顺序。这对于 v2 CNF 缩减也是一个限制。
KubernetesDriver 调用以下 API 以获取目标资源的当前副本数，更新副本数并检查资源状态：
API 组 |
类型 |
API 方法 |
|---|---|---|
AppsV1Api |
读取 |
read_namespaced_<kind> |
更新 |
patch_namespaced_<kind>_scale |
Read API 的参数是 name 和 namespace。
Update API 的参数是 name、namespace 和 body。body 设置为 Read API 返回的值的“spec.replicas”的更新值。
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
无
其他部署者影响¶
无
开发人员影响¶
无
实现¶
负责人¶
工作项¶
Implement KubernetesDriver 进程在 Tacker-conductor 上运行。
添加新的单元和功能测试。
更新 Tacker 用户指南。
依赖项¶
Tacker SPEC：支持 ETSI NFV-SOL_v3 错误处理操作 [3]
测试¶
将添加用于使用 Kubernetes VIM 进行 v2 CNF 回滚操作的单元和功能测试用例。
文档影响¶
将在 Tacker 用户指南中添加关于 v2 CNF 回滚操作的描述。
