修复并改进访问规则以及与共享驱动程序的交互¶

https://blueprints.launchpad.net/manila/+spec/fix-and-improve-access-rules

共享文件系统的一个主要优势是访问控制。Manila 的访问控制实现提供了一个易于使用的界面，用于允许和撤销客户端对共享文件系统的访问。访问控制基于适用于各个存储协议的相应访问类型。例如，对 NFS 共享的访问使用基于 IP 的规则进行控制，对 CEPH FS 共享的访问使用 CEPHX 访问规则进行控制，等等。在许多版本中，我们不得不修复许多访问控制 API 的问题，其中最主要的是不正确的 API 行为 [1] 和竞争条件 [2]。

问题描述¶

Manila 中的两个主要设计变更影响了访问规则的实现：引入共享实例 [3] 以及共享后端上的批量访问规则更新 [4]。在这些变更之前，行为如下

租户可以请求（或拒绝）对给定共享的客户端的访问权限
租户可以连续发送 x 个这样的请求
租户可以列出给定共享上的访问规则，并且每个规则都有一个不同的 state（状态），该状态会告知租户规则是否已成功应用或拒绝。

这种 API 行为易于编写脚本，甚至可以对给定共享执行批量访问规则操作。由于我们具有每个共享、每个规则的 state，并且每个访问规则都由共享驱动程序单独应用或拒绝，因此错误报告更好，并且发生竞争条件的可能性更小。

当前行为如下

共享具有实例。对于给定共享实例的访问规则，没有 state（状态），而是共享实例具有一个 access_rules_status（访问规则状态）属性，该属性是给定共享实例所有访问规则的组合状态。
租户不知道共享实例；访问控制仍然在共享级别执行。他们可以通过访问控制 API 添加或删除给定共享的规则。我们不支持一次修改多个访问规则，因此对 allow_access 或 deny_access 的 API 调用每次只会影响一个访问规则。
租户可以连续发送 x 个这样的请求，但是，如果规则仍在为给定共享实例处理中，access_rules_status（访问规则状态）将在共享实例上从“active”（活动）过渡到“updating”（更新中），从“updating”（更新中）过渡到“updating_multiple”（正在批量更新）。
如果后端或共享驱动程序无法处理某个请求，则会引发异常，并且 access_rules_status（访问规则状态）将被设置为“error”（错误）。在删除所有“坏”规则之前，将不允许进一步添加规则。
识别“坏规则”需要租户通过注意每个状态转换来进行仔细的监督；否则，服务器会假定所有规则都处于“error”（错误）状态——由于 Manila 数据库中没有跟踪每个共享实例、每个访问规则的状态。
当在同一共享上发出大量访问请求时，在某个时刻，共享管理器会忽略这些请求（即，共享实例的 access_rules_status（访问规则状态）从“active”（活动）过渡到“updating”（更新中）第一个新规则，当下一个规则到来并且状态仍然是“updating”（更新中）时，从“updating”（更新中）过渡到“updating_multiple”（正在批量更新）。如果进一步的请求在状态为“updating_multiple”（正在批量更新）时到来，则会被忽略。）[5]
此外，为了避免共享管理器中的竞争条件，与共享后端的整个交互都使用锁进行同步。如果共享驱动程序或后端花费很长时间，则锁会阻止任何进一步的操作。
如果共享管理器服务崩溃或在共享实例的 access_rules_status（访问规则状态）为“updating”（更新中）或“updating_multiple”（正在批量更新）时重新启动，用户将陷入困境。无法添加新规则，并且由于错误报告不佳。要从这种状态恢复，用户必须执行另一个访问规则 API 请求（拒绝现有客户端的访问权限）以触发访问规则的更新。
当引入共享实例作为共享副本和迁移实例的基础数据库表示时，设计充分认识到“实例”对管理员可见，而不是对最终用户可见（副本对租户可见，但是他们不需要知道副本是共享实例）。但是，错误消息 [6] 似乎打破了这种抽象。
当共享具有多个实例时，API 会向与每个实例对应的共享管理器主机发送 RPC 请求。当前逻辑如下
- 用户请求对共享的客户端的访问权限
- manila-api 对共享的状态进行基本验证
- 然后它将规则提交到数据库
- 它循环遍历共享的实例，验证每个实例并发送 RPC 请求。
- manila-api 在发送完所有 RPC 请求后，使用 202 Accepted（已接受）响应。
在这里，如果第二个或后续共享实例的验证失败，则 RPC 调用已经针对第一个共享实例发出，导致用户收到 400 Bad Request（错误请求）并且规则过渡到“error”（错误），但共享可能可以通过第一个实例的导出路径访问。

用例¶

对于共享文件系统的用户来说，访问控制可能是最基本的要求。拟议的更改将允许保留好的部分并增强 Manila 中访问控制的用户体验

用户可以快速连续地向给定共享添加任意数量的访问规则，只要 API 允许即可。
用户可以识别哪些规则/规则失败。
用户可以在某些规则处于“error”（错误）状态时继续应用或拒绝规则。
用户可以拒绝尚未应用的规则。

消除当前存在的竞争条件将使用户和云管理员受益。

提议的变更¶

将重新引入每个共享实例规则、每个访问规则的 state（状态）。
将引入四种新的访问规则状态：‘queued_to_apply’（当前为‘new’），‘queued_to_deny’，‘applying’ 和 ‘denying’，此状态转换如下
- 添加新规则
  
  当 API 收到请求时
  
  share_instance.access_rules_status
  - ‘active’（活动）——> ‘out_of_sync’（不同步）
  - ‘error’（错误）——> ‘error’（状态将被保留）
  - ‘out_of_sync’（不同步）——> ‘out_of_sync’（状态将被保留）
  share_instance_access_map.state
  - ‘queued_to_apply’（排队应用）——> ‘queued_to_apply’（规则从该状态开始）
  在共享管理器中，在将请求发送到共享驱动程序之前
  
  share_instance.access_rules_status
  - ‘error’（错误）/ ‘out_of_sync’（不同步）——> （状态将被保留）
  share_instance_access_map.state
  - ‘queued_to_apply’（排队应用）——> ‘applying’（应用中）
  当共享驱动程序返回响应时
  
  share_instance.access_rules_status
  - ‘error’（错误）——> ‘error’（状态将被保留）
  - ‘out_of_sync’（不同步）——> ‘active’（活动）（如果没有其他‘queued_to_apply’（排队应用）或‘queued_to_deny’（排队拒绝）规则）
  share_instance_access_map.state
  - ‘applying’（应用中）——> ‘active’（活动）或 ‘error’（错误）
- 删除现有规则
  
  当 API 收到请求时
  
  share_instance.access_rules_status
  - ‘active’（活动）——> ‘out_of_sync’（不同步）
  - ‘error’（错误）——> ‘error’（状态将被保留）
  - ‘out_of_sync’（不同步）——> ‘out_of_sync’（状态将被保留）
  share_instance_access_map.state
  - ‘active’（活动）——> ‘queued_to_deny’（排队拒绝）
  - ‘applying’（应用中）——> ‘queued_to_deny’（排队拒绝）
  - ‘error’（错误）——> ‘queued_to_deny’（排队拒绝）
  - ‘queued_to_apply’（排队应用）——> ‘queued_to_deny’（排队拒绝）
  在共享管理器中，在将请求发送到共享驱动程序之前
  - ‘queued_to_deny’（排队拒绝）——> ‘denying’（拒绝中）
  当共享驱动程序返回响应时
  
  share_instance.access_rules_status
  - ‘error’（错误）——> ‘error’（状态将被保留）
  - ‘out_of_sync’（不同步）——> ‘active’（活动）（如果没有其他‘queued_to_apply’（排队应用）或‘queued_to_deny’（排队拒绝）规则）
  share_instance_access_map.state
  - ‘denying’（拒绝中）——> ‘deleted’（已删除）或 ‘error’（错误）

注意

当共享具有多个共享实例时，预计所有共享实例都应具有相同的访问规则。

在共享迁移的情况下，虽然源共享实例的现有访问规则最终会应用于目标共享实例，但它最初没有任何访问规则。

此外，在迁移共享时，某些后端可能无法出于各种原因允许在迁移期间对源共享进行写操作。基于主机的迁移无法处理在复制现有数据时写入共享的新数据。为了确保所有写操作都被阻止，Manila 在这些类型的迁移之前将源共享上的现有规则转换为只读。

在共享复制的情况下，客户端仍然可以访问所有副本的期望仍然成立，并澄清语义：对于“dr”副本，我们跟踪数据库中的所有访问规则，但是，副本没有导出位置，因此，虽然数据库将这些规则包含为给定副本的“active”（活动），但副本不可访问。

对于“readable”（可读）副本，驱动程序会将任何读/写规则转换为辅助副本的只读规则；即，规则的数据库表示不会从“r/w”更改，辅助副本上的“r/o”语义由共享驱动程序本身固有地确保 [7] [8]。这种对驱动程序的期望是仅存在于此功能中的例外情况，即，确保只读语义的逻辑当前需要存在于每个驱动程序中，尽管共享管理器可以统一处理它，就像在共享迁移中一样。

有关更多详细信息，请参阅只读访问语义。

重要

如果预计所有共享实例都应具有相同的访问规则，为什么我们仍然需要维护每个访问规则、每个共享实例的状态？

虽然这可能与共享实例的目的和设计很清楚，但让我们再次澄清一下以供后人参考：每个共享实例都与 Manila 主机相关联。它们可以在不同的时间创建并独立操作，例如，考虑创建共享、允许访问，然后在稍后时间为其创建副本或迁移它。因此，访问控制的状态应按规则、按共享实例跟踪。这也是具有每个共享实例的 access_rules_status（访问规则状态）属性的好处。活动副本的 access_rules_status（访问规则状态）可以是“active”（活动），而对于尚未同步规则的辅助副本，该属性可以是“out_of_sync”（不同步）。但是，当用户列出访问规则时，将聚合每个共享实例的访问规则状态。有关更多详细信息，请参阅聚合状态字段。

规则状态更新将在 API 服务和共享管理器服务之间协调。如上所述，API 服务中现有规则的唯一状态转换是在拒绝规则时执行的。API 服务将获取与共享管理器服务相同的锁以进行此转换。
Manila-api 和 manila-share 都访问数据库；不需要访问规则有效负载，因为这些服务可以单独从数据库读取规则并执行必要的状态转换。因此，RPC：manila.share.rpcapi.ShareAPI.allow_access 和 manila.share.rpcapi.ShareAPI.deny_access 将合并到 manila.share.rpcapi.ShareAPI.update_access 中。
当共享管理器收到更新_访问 RPC 请求时，它将按如下方式进行反应
- 获取锁，查看数据库中给定共享实例的任何处于“applying”（应用中）或“denying”（拒绝中）状态的规则。如果有任何规则处于这些状态，则驱动程序当前正在处理规则更改，任何“queued_to_apply”（排队应用）或“queued_to_deny”（排队拒绝）规则将在驱动程序完成当前任务后批量应用或拒绝。以下步骤不会立即执行。如果没有规则处于“applying”（应用中）或“denying”（拒绝中）状态，则将任何“queued_to_apply”（排队应用）规则的状态设置为“applying”（应用中），将“queued_to_deny”（排队拒绝）规则的状态设置为“denying”（拒绝中）。释放锁。

注意

当驱动程序正在处理访问规则更新时，任何“queued_to_apply”（排队应用）或“denying”（拒绝中）规则都会保留不变，直到驱动程序从其当前任务返回。 update_access（更新访问）接口设计用于批量更新。规则处理没有顺序。如果需要以特定顺序处理访问规则，则由共享驱动程序来执行此操作。

调用驱动程序接口 update_access，传递现有规则和“changed”（已更改）规则（“applying”（应用中）或“denying”（拒绝中）规则）。
接受 state（状态）属性由驱动程序设置，允许驱动程序更新处于过渡状态的规则。如果驱动程序未为处于过渡状态的每个规则返回状态，则将“applying”（应用中）规则过渡到“active”（活动），并软删除处于“denying”（拒绝中）状态的规则。通过获取锁来读取当前状态并在事务结束时释放它来执行这些操作。
获取锁并读取可能出现的任何“queued_to_apply”（排队应用）规则，如果有，则重复最后三个步骤，否则继续下一步。
获取锁并将共享实例的 access_rules_status（访问规则状态）从 out_of_sync（不同步）过渡到 active（活动）。如果给定共享实例的任何访问规则处于“error”（错误）状态，则将保留“error”（错误）状态。

用于检索给定共享或给定共享实例的特定规则或所有规则的数据库 API 将被重构。
围绕 update_access（更新访问）驱动程序接口（或备用接口）的粗略锁将被删除。如上所述，将引入围绕这些访问规则的数据库调用的读写锁。这是因为 manila-share 和 manila-api 服务都可以读取和写入数据库。为了获得正确的行为，部署者应优先使用分布式锁 [9] 或位于共享文件系统上的文件锁。
在重新启动共享管理器服务时，访问规则的“恢复”步骤将更新。所有处于“applying”（应用中）状态的规则都将恢复到“queued_to_apply”（排队应用），然后再请求驱动程序同步给定共享实例的访问规则。
只读访问语义:

对于共享迁移和共享复制，给定实例的访问规则，共享迁移的源实例或共享的二级副本，可能需要设置为 r/o（只读）。

目前，代码可以确保迁移源共享实例的只读语义。此规范建议向共享实例的数据库表示中添加一个字段。

该字段将被称为 cast_rules_to_readonly。它将在迁移和复制工作流程中根据需要进行设置和取消设置。

当我们拥有该字段时，在 update_access 工作流程中执行检查，在调用驱动程序之前，将像这样简单：
```
if share_instance['cast_rules_to_readonly']:
    # The share manager will know to cast all rules to 'r/o'
    # before calling the share driver as long as this condition holds.
```
默认情况下，cast_rules_to_readonly 字段对于任何共享实例都将为 False。

当在支持 readable 风格复制的共享上创建新的副本时，该字段将被设置为 True。当副本被提升为主要（活动）副本时，该字段将被取消设置，并设置为 True，当副本被降级为二级副本时。

在每次需要迁移时，cast_rules_to_readonly 字段将在迁移开始时设置为 True，并且如果任何迁移被取消，则始终取消设置。

请注意，不支持复制共享的迁移，在迁移共享之前必须删除副本。

cast_rules_to_readonly 字段不会暴露给租户。它将在所有返回“详细”共享实例的 API 中暴露给管理员。它不会存在于共享模型中，甚至作为属性，因为它仅属于特定的共享实例。

设置和取消设置 cast_rules_to_readonly 将由锁同步。

支持只读规则是 manila 中的最低要求。如果驱动程序不支持它们，manila 功能的本次和未来演进将暴露差异并破坏抽象。已经有计划对这些差异采取行动，例如策略更改。对这些驱动程序的任何操作不在本规范的范围内。

聚合状态字段¶

为了尽可能地保持用户关心的 API 抽象，我们需要聚合共享实例 access_rules_status 以及每个实例访问规则 state 属性的状态字段。

share_access_map.state
非持久化，但反映了 share_instance_access_map.state 的聚合状态

聚合：读取所有 share_instance_access_map.state，优先顺序如下：‘error’、‘queued_to_apply’、‘queued_to_deny’、‘applying’、‘denying’、‘active’

share.access_rules_status
非持久化，但反映了 share_instance.access_rules_status 的聚合状态

聚合：读取所有 share_instance.access_rules_status，优先顺序如下：‘error’、‘out_of_sync’、‘active’

备选方案¶

没有每个共享实例的每个访问规则状态：活在现实之外，即进程会失败，事情会偶尔出错，甚至真正的用户错误也会扰乱编写良好的驱动程序或存储系统代码（有些驱动程序会在不理解规则类型时使整个请求出错）。如果我们现在不分离状态字段，我们将不得不支持恼怒的用户并记录如何摆脱混乱的情况。
没有过渡状态：允许像今天一样发生粗略的转换，并且不需要增加并发控制和糟糕的用户体验的好处，即允许所有规则转变为“error”。
保留共享管理器中的粗略锁：长时间持有锁会增加进程在持有锁时失败的机会，并且更有可能遇到死锁情况 [10]。
不要重构 API，允许错误消息保持不变：我们需要用户文档和对 manila 中共享实例的工作方式的了解。这破坏了抽象和设计，但也许不是在复杂的 OpenStack 生态系统中最糟糕的事情。
不要组合 RPC - 合理，但将它们分开没有真正的益处。
不要重构数据库 API 代码 - 合理，这是大量的代码变更，但同样，数据库调用的次数会增加，并且我们将因为不想解决这个问题而牺牲性能。
不要需要共享/分布式锁：另一种选择是在一个服务（manila-api 或 manila-share）中只发生状态转换。但是，所提出的设计在正确性方面更胜一筹。我们需要在行为变化方面做出妥协：例如，不允许在变为“active”之前拒绝规则；或者 manila-data 服务必须通过 manila-share 或 manila-api 创建新规则。生成的代码可能更简单，但功能损失将是向后不兼容的 API 更改。（这是 nova-conductor 式 manila-conductor 服务的完美理由。）

另一方面，如果部署者没有部署建议的 DLM 锁，并且仍然分发 manila-api 和 manila-share 服务，那么在合并所提出的实现时，发生竞争条件的可能性会更高。但是，这可能不会发生在很少或从不执行对同一共享的大量访问请求的某些云中。请注意，对访问 API 的任何脚本都可能会发现这些竞争条件。免责声明：推动这项工作的开发人员不赞同错误的部署实践。
与其将 cast_rules_to_readonly 字段添加到共享实例，我们可以演进代码中的一组条件来确保我们期望的共享实例的只读语义。
- 对于辅助迁移，我们可以参考指定主机是否支持对给定共享的只读访问的配置参数，并在 update_access 工作流程中，在调用驱动程序之前将所有访问规则更改为只读规则。
- 类似地，我们可以在 update_access 工作流程中确定任何 readable 副本，并在调用驱动程序之前将访问规则转换为只读。
- 对于 writable 和 nondisruptive 迁移，我们可以小心地确保在迁移时从不调用 update-access。
虽然这看起来很简单，但考虑到未来的功能，它似乎更复杂，难以维护。它还超载了多个状态字段的使用。这会创建一个瓶颈，并在 manila 中的任何进程更新这些状态字段时产生潜在的竞争条件。此外，我们需要确保在重新启动 manila 服务时保持一致的行为。有了这种动机，数据库中的一个字段似乎是必要的。
要求驱动程序更新规则的 state 属性。这是一个合理的请求。允许驱动程序更新哪些规则未成功应用，比在批量更新操作期间将所有过渡规则状态设置为“error”更有益。我们需要在共享管理器中编写代码，根据驱动程序是否决定返回每个访问规则的更新来执行规则更新。这与现有的其他驱动程序入口点类似。因此，虽然我们将鼓励驱动程序重新访问 update_access 接口并返回状态字段的更新，但作为这项工作的一部分，即使对于第一方驱动程序，也不可行。

数据模型影响¶

manila.db.sqlalchemy.models.ShareInstanceAccessMapping 模型将有一个名为 state 的新字段。

数据库升级步骤将通过填充现有 manila.db.sqlalchemy.models.ShareInstance.access_rules_status 列的值来添加此列。

manila.db.sqlalchemy.models.ShareInstance.access_rules_status 列的值将被重新映射，以删除“updating”和“updating_multiple”作为有效的 access_rules_status 值。

manila.db.sqlalchemy.models.ShareInstance 模型将有一个名为 cast_rules_to_readonly 的新字段。

数据库升级步骤将为所有具有 replication_type 属性设置为 readable 且 replica_state 不为 active（可读类型复制中的二级副本）的共享实例添加此列，默认值为 True。对于所有其他共享实例，该值将设置为 False。

在 ORM 层，manila.db.sqlalchemy.models.ShareInstanceAccessMapping 模型现在将包含对访问规则模型（manila.db.sqlalchemy.models.ShareAccessMapping）的反向引用。这样，与读取给定共享实例访问映射行相关的数据库 API 将可以访问相关的访问规则数据（例如 access_type 和 access_level）。

数据库降级步骤将从 manila.db.sqlalchemy.models.ShareInstanceAccessMapping 中删除 state 列。它不会更改 manila.db.sqlalchemy.models.ShareInstance.access_rules_status 列。

数据库降级步骤还将从 manila.db.sqlalchemy.models.ShareInstance 中删除 cast_rules_to_readonly 列。

与往常一样，不建议在生产云中进行降级。

REST API 影响¶

不会添加新的 API。虽然我们将增加微版本以暴露“queued_to_deny”状态，引入过渡“applying”和“denying”状态，但其他更改将在不增加微版本的情况下进行，因为 API 中的行为当前已损坏，并且鉴于不可预测/不受欢迎的行为，很难保证需要向后兼容性。

添加访问规则

POST /v2/{tenant-id}/shares/{share-id}/action BODY

{
    'allow_access': {
            "access_level": "rw",
            "access_type": "ip",
            "access_to": "0.0.0.0/0"
    }
}

首先完成策略检查，然后再进行任何其他验证
如果任何共享实例无效，API 将在数据库中创建规则之前返回。
在共享正在迁移时添加访问规则是可能的，只要所有共享实例都有一个有效的宿主。此行为仅从新版本的 allow-access API 中暴露。

拒绝访问规则

POST /v2/{tenant-id}/shares/{share-id}/action BODY

{
    'deny_access': {
           "access_id": "a25b2df3-90bd-4add-afa6-5f0dbbd50452"
    }
}

首先完成策略检查，然后再进行任何其他验证
如果任何共享实例无效，API 将在拒绝任何其他有效实例的规则之前返回。
当共享实例状态不是“available”时，无法拒绝访问规则。

列出访问规则

POST /v2/{tenant-id}/shares/{share-id}/action BODY
{
    'access_list': null
}

首先完成策略检查，然后再进行任何其他验证
引入的过渡状态将被映射到较早版本的状态，以用于微版本低于引入它们的版本的 API 请求。将“applying”和“queued_to_apply”映射很容易，它们将被设置为“new”；将“queued_to_deny”和“denying”映射很困难，因为状态在过渡到“denying”之前可能是任何状态。因此，我们将读取共享的聚合 access_rules_status，如果它是“error”，我们将把此访问规则的状态映射到“error”，否则如果 access_rules_status 是“out_of_sync”，规则的状态将被映射为“new”，如果 access_rules_status 是“active”，规则的状态将被映射为“active”。请注意，这是我们试图通过重新引入每个共享实例的每个访问规则状态来改变的行为。

共享实例 API

cast_rules_to_readonly 字段将在共享实例的“详细”视图中（仅限管理员）作为微版本化的更改暴露。

安全影响¶

批量访问规则更新将不再被 manila 忽略。我们还将支持在意外授予访问权限的情况下拒绝访问。由于状态更改的跟踪将得到改进，我们预计会对安全性产生积极影响。

通知影响¶

在 [11] 合并并完全支持于 manila 之前，没有。

其他最终用户影响¶

最终用户将在针对较新的 manila 版本编写应用程序时被提示首选新的微版本，以便充分利用更可预测的状态转换。当 manila 在他们的云中升级时，无论他们使用哪个 API 版本，他们已经可以从更快的 API 失败中受益。

性能影响¶

对 ORM 和数据库 API 的更改将减少对数据库的冗余调用，预计会对性能产生积极影响。与其对每个 RPC 请求做出反应并触发驱动程序上的 update_access 调用，所提出的实现会在驱动程序正在处理规则请求时推迟未应用的规则请求。这可能会导致一次性生效的请求批处理，从而减少对存储后端调用的次数，从而提高性能。

其他部署者影响¶

在添加 tooz 支持之前，我们预计部署者将使用 oslo_concurrency 创建的文件锁来支持 manila。在多节点部署中，这些文件锁必须可供运行所有 manila 服务的每个节点访问。通常，这是通过将这些锁存储在共享文件系统上来实现的。

一旦添加了 tooz 支持，此补丁中引入的同步将自动受益于 tooz 引入的锁定抽象；并且部署者可以选择在 manila/tooz 下方配置分布式锁管理系统。

由于服务中没有保存任何状态，因此所提出的更改不会引入任何回归来影响 active-active 部署选择。

开发人员影响¶

无

驱动程序影响¶

与往常一样，在拒绝规则时，如果规则在后端不存在，驱动程序不得引发异常，它们可以记录访问规则从未存在，并返回 None，允许从数据库中删除规则。

引发异常会将所有处于过渡状态的规则（“applying”或“denying”）设置为“error”。因此，驱动程序必须仔细考虑异常处理。

作为这项工作的一部分，我们将接受来自驱动程序的“error”规则状态的响应，因此，驱动程序可以告诉共享管理器哪些确切的规则未能应用。这需要添加到每个考虑如何处理错误报告的后端驱动程序中。

实现¶

负责人¶

主要负责人: gouthamr
其他贡献者: yogesh

rooneym

工作项¶

代码 - 为了便于实现和审查，这项工作将以多个相关的变更集完成，每个变更集将部分实现蓝图，直到所有建议的项目都实现为止。
服务器和客户端中的功能测试

依赖项¶

无

测试¶

将为 API 的更改添加负面/API 测试，包括调度无效的共享或无效的副本，以及在 API 层面测试访问规则的交互。
将修改现有的访问规则测试，以验证 access_rules_status，但在 manila 和 python-manilaclient 中等待访问规则的状态属性。
场景测试规范 [12] 建议添加围绕只读语义的测试。此简化应该通过建议的测试。