Spec Lite: 添加人类可读的导出位置支持

问题:

导出位置通常难以记忆。目前,在创建共享之前无法确定导出位置,因此用户必须等待共享创建请求完成,然后检查导出位置才能挂载共享。生成的导出位置通常不易于阅读和记忆,并且难以控制。

解决方案:

我们可以为共享引入一个新的字段,允许用户在共享创建时指定自定义导出位置。如果需要再次挂载共享,这将使他们更容易记住共享的导出位置。如果在创建请求期间指定了此字段,则支持此功能的后端能够为给定的共享创建多个导出位置,并且用户可以使用人类可读的导出位置,或者如果存在其他导出位置,也可以使用它们。 某些实现此功能的后端可能只能提供一个导出路径。 新字段将称为 mount_point_name,它将被添加到共享模型中。 此字段不接受除下划线以外的特殊字符。 如果提供除下划线以外的特殊字符,manila api 服务将引发 HTTP BadRequest 错误,警告这些字符不允许。 导出位置在共享服务器中必须是唯一的。 因此,当收到创建共享的请求时,如果提供了 mount_point_name,则项目名称将被添加到其前面。 用户提供的字符数加上项目名称中的字符数不能超过 255 个字符,否则请求将被拒绝。 认为用户可以轻松记住项目名称是合理的,因此与 ID 相比,它仍然是一个更好的选择,并且我们可以确保将项目名称附加到自定义挂载点名称不会偏离此提案的主要目标。 因此,manila 共享服务将查找重复的 mount_point_name 值,如果找到任何重复项,则创建将失败。 可能会出现不同域中的两个项目具有相同的名称,并且用户在创建共享时意外设置了相同的 mount_point_name。 在这种情况下,共享将不会被创建,其状态将被设置为错误。 将为这两种情况创建用户消息。 将添加一个新的后端功能,称为 human_readable_export_location_support,并且支持此功能的驱动程序应将其报告为 True。 管理员需要创建具有额外规范设置为 True 的共享类型。 由于 manila 共享 API 将使用此额外规范执行验证,因此它必须始终对租户可见。 通过此额外规范,调度程序还可以过滤掉不支持此功能的后端。 在共享迁移的情况下,如果提供了新的共享类型,并且它具有 human_readable_export_location_support=True,如果选择的目标后端不支持它,则迁移将在调度程序中失败。 如果指定了新的共享类型,并且与以前的不同之处在于它不支持导出位置的自定义名称,则迁移将成功,不会创建自定义导出位置,并且 mount_point_name 字段值将被设置为 None。 管理员可以通过名为 --new-mount-point-name 的新参数,在 migration-start 命令中配置迁移的共享的自定义挂载点名称。 这将帮助管理员避免由于迁移中重复的自定义导出位置而导致的可能故障。 因此,在共享创建场景中,用户可以创建如下共享

$ manila create nfs 1 --name share_name --mount-point-name custom_export_path

用户可以使用自定义导出位置挂载共享,如下例所示

$ sudo mount -t nfs 10.1.0.2:/project_name_custom_export_path /mnt/my_share
影响:
  • REST API 影响。
    • 共享 API 的微版本更新。

    • API 将接受字段 mount_point_name

  • 文档影响
    • 用户指南

    • API 参考

    • 贡献者指南

  • 数据库影响
    • 一个名为 mount_point_name 的新字段将被添加到 shares 模型中。

  • Python-manilaclient 和 OSClient 影响
    • 共享 create 命令将被修改为接受共享创建中的 --mount-point-name 参数。

    • migration-start 命令将被修改为接受 --new-mount-point-name 参数。

此实现不应影响任何方面的性能。

替代方案:

作为替代方案,驱动程序可以重用共享的名称和描述,并生成人类可读的导出位置,但名称可能会重复,并且后端可能会因该原因而失败。

时间线:

包含在 Xena 版本中。

链接:

https://blueprints.launchpad.net/manila/+spec/human-readable-export-locations

负责人:

carloss