删除带有相关快照的卷

https://blueprints.launchpad.net/cinder/+spec/del-vols-with-snaps

允许删除带有现有快照的卷。建议将此功能集成到现有的卷删除路径中，使用一个额外的参数来请求在删除卷时同时删除快照。

问题描述

在删除卷时，如果该卷存在快照，删除操作可能会失败。调用者被迫检查快照信息并进行多次调用来删除快照，即使他们对快照不感兴趣，只想删除卷。

由于快照在我们的模型中是卷的“子项”，因此出于可用性和性能的考虑，允许在一个操作中删除卷及其快照是合理的。

用例

  • 对最终用户来说，更友好和预期的行为。

目前，如果一个卷有快照，基本用户体验是

  1. 尝试删除卷

  2. 收到关于其具有快照的错误消息

  3. 手动删除 X 个快照，略感沮丧

  4. 删除卷

  • 对于与 Cinder 集成的其他软件来说，更简单。

我收到一个关于此功能的请求，因为一个与 Cinder 集成的项目希望能够直接删除卷，而无需处理相关的逻辑。我认为这是一个合理的观点（就像认为用户不应该处理这个问题也是合理的）。

  • 对于某些卷驱动程序来说，速度更快、效率更高。

在需要 cinder-volume 和后端之间来回通信以删除卷和快照时，存在两次性能损失

  1. 花费额外的时间来检查 X 个请求的状态。

  2. 花费时间将快照数据合并到另一个快照或即将被删除的卷中。

这意味着我们目前强制执行“全部删除”操作，比它实际需要的 I/O 和时间更多。（具体程度取决于特定的后端。）

提议的变更

卷删除操作应默认处理此问题。

阶段 1

这是通用/“非优化”情况，适用于任何卷驱动程序。

当收到卷删除请求时

  1. 查找属于该卷的快照，将它们全部设置为“正在删除”状态。

  2. 将卷设置为“正在删除”状态。（在 #1 之后完成，以尽量减少与我们当前状态转换模型的偏差。）

  3. 为每个快照发出快照删除请求。（此循环发生在卷管理器中。）

  4. 如果任何快照删除操作失败，则使操作失败并确保卷返回到可用状态。任何已成功删除的快照保持删除状态。任何删除失败的快照都标记为‘error_deleting’。根据错误的类型，继续删除快照或停止可能是有意义的。我们需要在实施过程中获得一些经验才能确定细节。

  5. 卷管理器现在将所有处于‘deleting’状态的快照移动到已删除状态。（volume_destroy/snapshot_destroy）

阶段 2

此情况适用于希望以优化方式处理批量卷/快照删除的卷驱动程序。

当收到卷删除请求时

从卷管理器开始…

  1. 检查驱动程序是否具有‘volume_with_snapshots_delete’功能。（名称待定。）这将是一个新的 abc 驱动程序特性。

  2. 如果驱动程序支持此功能，则调用 driver.delete_volume_and_snapshots()。将传递卷和所有相关快照的列表。

  3. 驱动程序抛出的任何异常都将指示一切都已成功删除。驱动程序可以返回信息，指示卷本身完好无损，但快照操作失败。

  4. 卷管理器现在将所有快照和卷从‘deleting’移动到已删除状态。（volume_destroy/snapshot_destroy）

  5. 如果发生异常，则将卷和所有快照设置为‘error_deleting’。我们没有足够的信息来安全地执行任何其他操作。

  6. 驱动程序返回一个字典列表，指示卷和每个快照的新状态。这允许处理某些内容删除成功但过程未完成的情况。

备选方案

  • 作为卷删除中的默认行为实现。- 目前认为这不是一个合适的更改。

  • 将此作为单独的卷操作引入，而不是在标准的卷删除路径中。- 如果没有客户端修改，则无法帮助可用性。

数据模型影响

没有直接影响。

在实施过程中，我们需要确保不会出现奇怪的情况，例如一个处于“正在删除”状态的卷具有处于“可用”状态的快照。因此，在此模型中，单个快照删除失败可能会导致将卷和所有其他相关快照标记为出错。（仅适用于上述阶段 2。如果我们让快照和卷删除操作在内部保持分离，则不会发生这种情况。）

REST API 影响

在删除卷调用中添加一个布尔参数“delete_snapshots”，默认值为 false。

先前返回 400 的带有快照的卷删除现在将成功。

安全影响

无。

通知影响

无。

所有快照/卷删除通知仍然会被触发。

其他最终用户影响

cinderclient 中用于 volume-delete 的新 –delete-snapshots 参数。

性能影响

  • 删除卷和所有快照的人应该能够更快地完成此操作，并使用更少的 REST 调用。

  • 某些存储后端将经历更少的负载，因为它们不必合并正在删除的快照。

其他部署者影响

无。

开发人员影响

  • 新的可选驱动程序接口
    def delete_volume_and_snapshots(volume, snapshots[])

    这应该采取驱动程序特定的任何必要步骤来删除快照和相关的卷数据。

    可以假定任何快照删除失败都会导致卷失败，因此这不必考虑部分失败。

  • 注意：这不需要在卷管理器之上发生，因为卷管理器处理所有相关状态更新。

实现

负责人

主要负责人

eharney (规范，部分实施)

其他贡献者

其他参与者 (实施)

工作项

调查

  • 了解与公共/共享快照的交互。

实现

大致顺序应该是：* 添加对卷删除 API 中新参数的解析 * 实施卷管理器逻辑以删除所有内容 * 创建一个新的 abc 类用于新的驱动程序接口 * 实施卷管理器逻辑以与新的驱动程序接口通信 * 为 LVM 驱动程序实施优化情况

依赖项

无

测试

将添加 Tempest 测试来涵盖此内容。

文档影响

需要记录卷删除调用的新行为，以及相关的客户端示例等。

参考资料