策略弃用

https://blueprints.launchpad.net/oslo?searchtext=policy-deprecation

多个 OpenStack 项目已经将它们的策略移动到代码中，并将其视为配置。这为开发者和操作员带来了诸多好处。将策略移动到代码中并记录它是 Queens 版本的一个社区范围内的目标。

问题描述

OpenStack 中的策略管理一直以来都是操作员和开发者痛点。操作员很难知道在不同版本中策略发生了哪些更改或添加，而必须手动比较策略文件。开发者无法以编程方式向用户传达策略文件的更改。

现在，由于项目会将策略移动到代码中，我们有机会使用 oslo.policy 来宣传策略的弃用和未来移除。这为开发者提供了一种以编程方式进行策略更改并以他们已经知道如何使用的方式向操作员传达这些更改的方式。这与我们在 OpenStack 中弃用其他内容的方式一致，例如配置选项。

用例

以下列表描述了 oslo.policy 中的弃用功能需要涵盖的情况

  • 以向后不兼容的方式更改策略的语义

  • 重命名策略

  • 以向后不兼容的方式移除策略，但具有过渡计划

这些可以在实际用例和示例中进一步说明

  1. 作为开发者，我需要能够使用 oslo.policy 更改策略的默认角色或规则

  2. 作为开发者，我需要能够使用 oslo.policy 重命名策略

  3. 作为操作员，我需要知道策略的默认角色或规则是否正在更改，以便我可以将旧策略复制粘贴到我的策略文件中，或者创建新默认值所需的角色

  4. 作为操作员，我需要知道我正在覆盖的策略是否将被重命名或移除，以便我的部署中的 API 不会意外地未受保护或以不安全的方式暴露

示例 1

策略 "foo:create_bar": "role:fizz" 需要将其策略值更改为 "role:bang"。在升级时，操作员可以执行以下两种操作之一。第一种选择是将原始策略复制粘贴到策略文件中，并覆盖 foo:create_bar 的新默认值。第二种选择是让操作员在他们的部署中创建角色 bang，以便在升级后可以使用新的默认值。可以将此过程应用于 rule 评估，以代替 role。

示例 2

策略 "foo:post_bar": "role:fizz" 应该替换为 "foo:create_bar": "role:fizz"，以与其他服务使用的策略保持一致。只要角色或规则检查保持一致，对使用默认值的操作员不应产生影响。服务的较新版本将开始使用 create_bar 进行策略执行，逐步淘汰 post_bar 的使用。

如果操作员正在覆盖 post_bar 的策略，则应记录一条消息，说明 post_bar 将不再是一个可执行的策略，并且应使用 create_bar 代替。这将使操作员有机会在 post_bar 完全消失之前修复他们的策略。这确保了操作员不会意外地暴露 create_bar，如果他们正在使用自定义策略来保护它的话。

示例 3

策略 "foo:bar": "role:bazz" 应该分解为

  • "foo:get_bar": "role:bazz"

  • "foo:list_bars": "role:bazz"

  • "foo:create_bar": "role:bazz"

  • "foo:update_bar": "role:bazz"

  • "foo:delete_bar": "role:bazz"

这使开发者或操作员能够将不同的角色与 bar 实例的不同操作相关联，而不是所有 bar 上的操作都需要 bazz 角色。

提议的变更

oslo.policy 库公开了一个 DocumentedRuleDefault 对象，策略注册为该对象。我们可以扩展此对象以支持可选的 deprecated 属性，或一组传达有关弃用信息的属性。这不需要项目更改其当前的策略定义或实现。以下是向项目公开的有用属性，以便他们改进策略

  • deprecated_for_removal：这是一个布尔值，表示策略是否已弃用

  • deprecated_reason：这是一个字符串，包含移除或弃用策略的理由

  • deprecated_since：策略正式弃用的版本

这些附加属性应与 oslo.config 的弃用功能非常相似，甚至相同。此更改可能仅限于 oslo.policy 库，特别是 DocumentedRuleDefault 对象。

标记为弃用的策略将发出与使用弃用的配置选项类似的日志警告。同样，弃用的策略将在生成的示例策略文件中标记为已弃用。

备选方案

开发者可以继续依赖发布说明和邮件列表来向操作员传达策略更改。这被认为是不理想的，因为它容易出错，缺乏跨项目的持续性，并且不可编程。因此，策略很少从其原始定义中更改，这非常成问题，因为策略无法随项目一起发展。

这实际上是我们今天唯一的替代方案，但由于它实际上并不能帮助改进策略，因此可以认为它根本不是替代方案。

Impact on Existing APIs

将改进 DocumentedRuleDefault 或 RuleDefault 的 API 以支持传达弃用的策略。

安全影响

使用此更改的项目可以通过提供更安全的默认规则来提高安全性。

性能影响

无。

Configuration Impact

不需要新的配置选项来使用或利用此功能。一旦项目拥有支持 oslo.policy 中 DocumentedRuleDefault 中弃用信息的版本，它就可以使用。

开发人员影响

除非开发者正在寻找改进或修改项目的策略，否则他们不会受到影响。如果是这样，他们可以使用新功能来描述弃用的原因、何时移除以及替代方案是什么。

Testing Impact

我们需要确保弃用的策略在被调用时发出某种警告。这可能可以在 oslo.policy 的测试中完成，但也可以在消耗测试的项目中完成。一个值得讨论的事情可能是添加一个标准，要求对弃用策略进行单元测试。

实现

负责人

主要负责人

Lance Bragstad <lbragstad@gmail.com> lbragstad

其他贡献者

无

里程碑

完成目标里程碑：queens-1

在 Queens 版本的早期提供此功能将允许项目在 Queens 发布之前弃用策略。

工作项

  • 在 RuleDefault 或 DocumentedRuleDefault 对象中实现弃用功能

文档影响

可能许多项目将使用此功能来弃用和改进他们现有的策略。这些弃用标志的使用应该有充分的文档记录。

依赖项

无。

参考资料

无。

注意

本作品采用知识共享署名 3.0 非移植许可协议授权。 http://creativecommons.org/licenses/by/3.0/legalcode