改进配置操作的错误处理¶

https://blueprints.launchpad.net/sahara/+spec/error-handling-in-provisioning

目前配置过程中的错误处理分散在整个配置代码中。本规范旨在统一错误处理，并将其集中在一个地方。

问题描述¶

目前配置部分存在两个与错误处理相关的问题

代码无法正确处理用户在配置过程中删除集群的情况。在这种情况下，可能会在许多地方引发任意错误。
代码仅在某些地方执行回滚，而实际上可以在任何配置/扩展阶段执行回滚。

以下 CR：https://review.openstack.org/#/c/98556 大部分解决了问题 #1，但其中包含大量重复代码。

提议的变更¶

以下是建议的解决方案，它需要架构上的更改，但可以更可靠地解决这两个问题

对于集群创建和扩展，将错误处理逻辑移动到 ops.py 文件中的最顶层函数。一旦捕获到异常，就正确处理它
1. 如果集群对象在数据库中不存在，则表示用户在配置过程中删除了集群；处理它并返回
2. 如果集群对象存在，则记录它并执行回滚
除了处理可能无限期挂起的情况外，不要在 ops.py 之外的地方检查集群是否存在。

我们可以采用以下回滚策略

对于集群创建：如果出现任何问题，则杀死所有 VM 并将集群移动到“Error”状态。

对于集群扩展：这将很长。集群扩展包含以下阶段

停用不需要的节点（由插件执行）
终止不需要的节点并创建新的节点（如果需要）（由引擎执行）。请注意，扩展和缩减可以同时运行，但位于不同的节点组中。
配置并启动节点（由插件执行）

如果发生相应阶段的异常，我的建议是

将集群移动到“Error”状态
杀死不需要的节点（完成缩减）。同样，如果为扩展而创建了新节点，也杀死它们。
将集群移动到“Error”状态

在情况 #1 和 #3 中，删除未停用或未配置的节点是危险的，因为这可能导致数据丢失。

替代方案¶

继续支持当前代码。它不够优雅，但效果足够好。

数据模型影响¶

无

REST API 影响¶

无

其他最终用户影响¶

数据配置逻辑将发生很大变化。这可能导致在不同阶段发生错误时行为发生变化。

部署者影响¶

无

开发者影响¶

配置引擎 API 将扩展“rollback_cluster”方法。

Sahara-image-elements impact¶

无

Sahara-dashboard / Horizon 影响¶

无

实现¶

负责人¶

主要负责人: alazarev
其他贡献者: dmitrymex

工作项¶

实施更改
测试集群配置和回滚在所有功能矩阵上是否有效。

依赖项¶

无

测试¶

配置可以手动和通过 CI 进行测试。测试回滚要困难得多。即使当前代码也没有得到很好的测试（例如 https://bugs.launchpad.net/sahara/+bug/1337006）。

文档影响¶

无

参考资料¶

无

改进配置操作的错误处理