This work is licensed under a Creative Commons Attribution 3.0
Unported License.
http://creativecommons.org/licenses/by/3.0/legalcode

容器别名

容器别名使得链接到其他容器成为可能，甚至可以链接到不同账户中的容器。

问题描述

目前，访问其他账户中的容器比访问在存储 URL 返回的账户中定义的容器更复杂，因为您需要使用与您的认证端点返回的不同存储 URL - 而并非所有客户端都支持这一点。 即使您可以通过选择的客户端知道并支持共享容器的存储 URL，在对用户账户执行 GET 请求时，共享容器也不会被列出，因此常规客户端应用程序或用户无法发现它们。

容器别名可以简化此任务。 具有创建容器权限的 swift 账户所有者/管理员可以在用户已经具有访问权限（很可能通过 ACL）的容器上创建别名，并将根源于或位于此别名下的请求重定向或代理到不同账户中的第二个容器。

这将简化了出于各种原因使用现有客户端访问这些容器的过程。

1. 在账户级别执行 GET 请求将列出这些容器
2. 对别名容器的请求将被转发到目标容器，从而可以在客户端无需使用不同的存储 URL 的情况下访问该容器。

但是，设置别名仍然需要存储 URL（请参阅 自动容器别名配置 以了解未来的替代方案）。

注意事项

如果源容器中有对象，则设置别名应该是不可能的，因为这些对象将变得无法访问，但仍然需要存储空间。 如果在容器创建的同时（以及几毫秒内？）存储对象并设置别名，则可能存在竞争条件。

类似于存储策略中使用的协调机制可以解决此问题，并确保仅在容器创建期间才能设置别名。 取消设置别名将被拒绝，而是要删除别名容器。

提议的变更

需要设置和审查的新元数据，以及存储在容器别名上的系统元数据 - 目标容器。

大部分所需的更改可以放入一个单独的中间件中。 存在一个现有的补丁：https://review.openstack.org/#/c/62494

注意

该补丁的主要问题是，在切换期间创建的容器（没有别名）可能会遮蔽预先存在的别名容器，并且在上传期间可能会导致用户对数据写入的位置产生困惑和潜在的无法解决的问题。

有人建议使用协调过程将别名容器中的对象移动到目标容器，从而允许最终一致性地修复分割大脑容器。

安全性

测试并验证在尚未进行身份验证的情况下会发生什么情况；确保尊重 ACL，并且不可能对其他账户中的容器进行未经授权的请求。

该更改应包括功能测试，以验证跨账户和非 swift 所有者跨容器别名是否正确尊重目标 ACL - 即使在某些情况下它们似乎重复了基于存储 URL 的跨账户/跨容器 ACL 测试。

如果允许后台进程移动存储在稍后确定为别名的容器中的对象，则如果目标上的 ACL 发生更改，可能会产生授权影响。

文档

更新文档并记录行为。

工作项

进一步的设计讨论。

负责人

主要负责人

cschwede <christian.schwede@enovance.com>

未来工作

自动容器别名配置

跨账户容器共享可能会得到进一步简化，从而带来更好的用户体验。

假设有两个用户位于不同的账户中

test:tester和test2:tester2

如果test:tester将 ACL 放在一个容器上/AUTH_test/container以允许访问test2:tester2，中间件可以创建一个别名容器/AUTH_test2/test_container链接到/AUTH_test/container。这将使发现其他用户/账户的共享容器成为可能。 但是，存在两个挑战

1. 名称冲突：可能存在一个现有的容器/AUTH_test2/test_container2. 查找需要将账户名称解析为账户 ID

跨领域容器别名

可能可以绑定到容器同步领域（或类似的东西），以允许操作员让用户代理请求到其他领域。