我尝试了一些负面场景，看看在什么情况下虚拟机会在 OpenStack 部署中陷入构建状态。一种情况是，当发出部署请求并且同时 nova-conductor 关闭时，则“schedule_and_build_instances” rpc调用将在rabbitmq队列中。现在由于某些原因，如果rabbitmq也重新启动，那么消息会丢失，因为conductor仍然处于关闭状态。 即使导体被带回来，请求/消息也会在重新启动时丢失。这会导致虚拟机条目仅位于 build_requests 表中。 现在，打开堆栈服务器列表将显示虚拟机处于构建状态，并且我们也无法重置为错误状态。它需要手动干预才能将其从数据库中清除。 有谁知道这些负面情况以及如何自动处理它们？ 一种方法是有一个定期任务，它将定期检查 build_requests 表，并查看某个请求是否卡住了很长时间，可以将其删除，或者我们必须手动将实例更新为构建请求中的错误状态。
处理 OpenStack 部署中的不一致确实具有挑战性。看来您已经考虑了虚拟机陷入构建状态问题的潜在解决方案。
以下是您可以考虑的一些方法：
您已经提到过这种方法。您可以创建一个定期任务（例如 cron 作业），定期检查 build_requests 表中是否存在卡住时间过长的条目。如果发现任何错误，它可以尝试重新启动构建过程或将它们移至错误状态，以避免它们无限期地卡住。
OpenStack 服务通常具有内置机制来检查各种组件的运行状况。您也许能够利用这些机制来自动检测和修复构建请求卡住的问题。