强制删除集群¶

https://blueprints.launchpad.net/sahara/+spec/sahara-force-delete

让我们解决一个长期存在的抱怨。

问题描述¶

经常报告的问题是，Sahara 集群在删除时会卡住。这可能会给用户带来很大的麻烦，而且看起来也很糟糕。通常，问题不是 Sahara 的错，而是某些无法删除的资源造成的。

提议的变更¶

我们将利用 Heat 的堆栈放弃功能。本质上，这意味着堆栈将被删除，但会保留资源。这是在堆栈中存在无法删除（或删除速度慢）的资源时，作为最后的手段。

这将通过 Sahara API 的新补充来实现，它封装了 Heat 堆栈放弃。并且最好将其作为 APIv2 的一部分发布，而不是继续破坏我们为 APIv1.1 经常打破的规则。

请注意，即使 Heat 堆栈放弃不会清理任何资源，我们也不应该让 Sahara 尝试手动清理它们。

上述观点有两点理由

这个 gerrit 注释 [0]
如果需要放弃，删除资源实际上非常困难

最好创建一个封装堆栈放弃的 API，而不是仅仅告诉用户直接使用放弃，因为在集群删除期间还有其他清理工作要做。有关更多信息，请参阅 [1]。

该变更将启用以下工作流程：调用强制删除并尽可能地清理集群，然后用户可以自行处理孤立资源。由于通过 Sahara API 进行显式放弃，用户始终被鼓励首先确保堆栈处于删除状态，从而最大限度地减少孤立资源的数量。

关于上述观点，绝对重要的是我们不要简单地增强常规删除调用以包含放弃调用。避免这种情况有两个关键原因

在正常操作中，Heat 堆栈删除会重试
在正常使用中，用户可能希望集群在资源实际消失之前保持在删除状态：强制删除只是为了紧急情况

替代方案¶

只是告诉用户/操作员手动使用 Heat 的堆栈放弃。由于上述原因，这不是一个好的选择。

数据模型影响¶

无

REST API 影响¶

我们将添加以下端点

DELETE /v2/clusters/{cluster_id}/force

与常规 DELETE 一样，成功时将返回 204。
它将以通常的方式返回通常的 4xx 错误。
当 Heat 堆栈放弃不可用时，它将故意返回 503。
请求体、标头、查询等与常规 DELETE 相同。

再次强调，最佳实践是使其成为 v2 独有的，而不是进一步破坏现有的 v1.1 API。

其他最终用户影响¶

需要扩展 Saharaclient API 绑定和 OSC 以支持新的 API 方法。

部署者影响¶

他们需要在 heat.conf 中启用 enable_stack_abandon=True，并确保他们的云策略允许用户执行此操作。

我们可以尝试使用 RBAC 和信任来做一些花哨的事情，以便 Sahara 服务用户可以代表用户放弃 Heat 堆栈，当操作员希望限制堆栈放弃时。但这可能不值得为此而烦恼……

开发者影响¶

无

镜像打包影响¶

无

Sahara-dashboard / Horizon 影响¶

是的，在 UI 中公开此功能。我们还可以添加一些关于强制删除含义的警告。

实现¶

负责人¶

主要负责人: Jeremy Freudberg
其他贡献者: 无

工作项¶

删除最后一点直接的引擎代码（如果没有此变更，即使是放弃的堆栈也可能卡住，因为 Sahara 引擎正在尝试手动清理；这也意味着在进行此变更后，完全删除的堆栈但集群仍然处于删除状态的错误基本上已解决……）
创建新的 API 部分和相应的操作
为客户端和仪表板添加功能

依赖项¶

无

测试¶

对于此功能，可能不需要严格的场景测试。

除了显而易见的单元测试外，还将更新 tempest 插件中的 API 测试。

文档影响¶

没有什么不同寻常的，但重要的是要牢记操作员和开发人员的视角。

参考资料¶

[0] https://review.openstack.org/#/c/466778/20/sahara/service/engine.py@276

[1] https://github.com/openstack/sahara/blob/master/sahara/service/ops.py#L355

强制删除集群