项目间共享迁移

https://blueprints.launchpad.net/manila/+spec/transfer-share-between-project

添加支持共享迁移，允许用户将共享迁移到其他用户所属的其他项目，就像 cinder transfer-create、transfer-accept、transfer-delete 一样。有两种场景，第一种是 DHSS=False，第二种是 DHSS=True。在第一种场景中，将仅支持迁移未绑定到共享网络的共享。迁移对象是共享。在第二种场景中，我们将支持迁移共享网络，这将导致其所有共享一起迁移。这将在另一个规范中完成。

问题描述

在实际的 OpenStack 生产环境中，用户通常会将存储资源转移给其他用户进行协作管道工作。Manila 共享也需要一种安全的方式来迁移共享，以便其他用户可以安全地接收它们。

用例

• 项目 A 中的用户为项目 B 中的另一个用户预填充数据。

• 当项目“结束”/被弃用时，共享数据可以迁移到仍然需要的项目。

• 将共享迁移到特定用户以协作完成剩余工作。

提议的变更

本规范建议

• 添加一个新的表，命名为 transfers。包含以下字段

  • id 表的主键。

  • resource_type 正在迁移的资源类型，可以是共享、共享网络等。

  • resource_id 正在迁移的资源的 UUID。

  • name 迁移的显示名称。

  • salt 用于计算 crypt_hash 的短随机字符串，创建迁移后将返回 auth_key（也是一个短随机字符串），salt 和 auth_key 通过 sha1 计算 crypt_hash。

  • crypt_hash 迁移的哈希值。

  • expires_at 迁移的过期时间，在创建后一小时（默认）之后。

  • source_project_id 共享的源项目 ID。

  • destination_project_id 共享的目标项目 ID。

  • accepted 共享是否已被接受。

• 为正在迁移的共享添加一个新的状态 awaiting_transfer。

• 在创建共享迁移之前检查以下内容

  • 检查共享、共享快照和共享副本的状态，共享和所有共享快照必须为 available。

  • 检查共享是否在共享组中，共享不能在共享组中。

  • 检查共享是否有共享网络，此规范仅支持第一种场景（DHSS=False），没有共享网络的共享将被允许迁移。

• 在接受迁移之前检查以下内容

  • 检查目标项目的配额，包括项目配额、项目用户配额、项目共享类型配额、per_share_gigabytes，确保目标项目有足够的剩余配额。

  • 如果源共享的共享类型不是公共的，并且共享类型的共享类型访问权限不包括目标项目，则将无法接受迁移。

• 出于安全原因，如果迁移在创建后一小时（默认）内未被接受，则迁移将自动取消。将有一个定期任务每 5 分钟检查一次过期的迁移。

• 添加一个新的配置项 wait_transfer_timeout_seconds，默认值为 3600 秒。

• “transfer-accept”需要调用驱动程序来完成 project_id 的更改，例如 CephFS 驱动程序将 project_id 存储为元数据。父类驱动程序仅定义函数，但不实现它。

• 在接受迁移时，用户可以选择是否需要清除共享访问规则。默认情况下，共享访问规则将不会被清除。

• 为 transfer-create、transfer-accept、transfer-delete、transfer-list、transfer-show 添加新的 API。

• 上述 API 更改将提升一个新的微版本。

备选方案

• 这里的一个替代方案是 manage/unamanage，项目 A 中的共享可以被特权用户“取消管理”，并“管理”到另一个项目。但是，这种方法存在两个问题

  • manage/unmanage 旨在具有破坏性 - 预先存在的访问规则将被刷新，并且共享将被重新导出。

  • 由于默认的 RBAC，您需要成为特权用户，因为这种方法放弃了云的抽象。

数据模型影响

• 将添加一个新的表 transfers。

REST API 影响

• 创建共享迁移

POST /v2/share-transfers

请求示例

{
    "transfer":
    {
        "share_id": "da8eb12e-123c-49ea-ae2b-5d42f02fa00e",
        "name": "share transfer"
    }
}

响应示例

{
    "transfer":
    {
        "auth_key": "qbgcabtdbad29r08",
        "created_at": "2021-12-27T11:29:46.743632",
        "name": "share transfer",
        "share_id": "da8eb12e-123c-49ea-ae2b-5d42f02fa00e",
    }
}

在接受共享迁移时，auth_key 是必需的，请妥善保存记录，因为稍后无法检索它。

• 接受共享迁移

POST /v2/share-transfers/{transfer_id}/accept

请求示例

{
    "accept":
    {
        "auth_key": "6461646164641397",
        "clear_access_rules": "false",
    }
}

• 列出项目的共享迁移

GET /v2/share-transfers

• 列出共享迁移和详细信息

GET /v2/share-transfers/detail

• 显示共享迁移详细信息

GET /v2/share-transfers/{transfer_id}

• 删除共享迁移

DELETE /v2/share-transfers/{transfer_id}

安全影响

• 这些迁移 API 都将受到 RBAC 的保护。

• 用户只能迁移属于他们项目的共享。

• 迁移 ID 和迁移 auth key 预计将通过非同步方式传递。迁移 auth key 仅在创建迁移期间由 API 返回。创建迁移后将无法检索迁移 auth key。

• 生成 auth_key 的加密算法的选择以及迁移 ID 是不可猜测的 UUID 的事实将为该过程提供额外的安全性。

• 由于迁移在一小时（默认）后过期，因此对这个关键命名空间更改具有时间限制的保护。

通知影响

当启动卷迁移并接受卷迁移时，我们必须通知外部侦听器。

其他最终用户影响

Manila 客户端、CLI 将扩展以支持共享迁移。

• 创建共享迁移的命令将如下所示

  openstack share transfer create <share>
  

• 接受共享迁移的命令将如下所示

  openstack share transfer accept [--clear-rules] <transfer> <auth_key>
  

• 列出共享迁移的命令将如下所示

  openstack share transfer list
  

• 显示共享迁移详细信息的命令将如下所示

  openstack share transfer show <transfer>
  

• 删除共享迁移的命令将如下所示

  openstack share transfer delete <transfer>
  

性能影响

无

其他部署者影响

无

开发人员影响

使用项目和用户基于元数据的驱动程序必须实现新的驱动程序接口来完成“transfer_accept”。

实现

负责人

主要负责人

haixin <haix09@chinatelecom.cn>

工作项

• 更新 API。

• 更新数据库

• 更新管理器。

• 更新 Manila CLI 命令。

• 更新单元和 tempest 测试。

• 更新相关文档。

• 更新 Manila UI。

依赖项

无

测试

• 添加单元测试

• 添加 tempest 测试

文档影响

以下 OpenStack 文档将被更新以反映此更改

• OpenStack 用户指南

• OpenStack 贡献者指南

• OpenStack API 参考

参考资料

基于 cinder 迁移策略。包括以下内容

• https://blueprints.launchpad.net/cinder/+spec/improve-volume-transfer-records

• https://blueprints.launchpad.net/cinder/+spec/transfer-snps-with-vols