示例规范 - 您的蓝图标题¶

https://blueprints.launchpad.net/congress/+spec/multiple-policies

目前，人们只能使用几种不同的策略。我们希望启用人们使用多种策略，以实现模块化和封装。

问题描述¶

我们希望用户能够创建和删除整个策略。我们希望用户能够选择他们想要创建的策略类型。我们希望用户编写的策略能够像引用数据源中定义的表一样自然地引用其他策略中定义的表。

提议的变更¶

用户可以创建/删除任意数量的策略并为其命名。这些策略中的每一个都类似于我们今天拥有的分类策略。

用户可以像今天对分类策略一样，向每个策略中插入/删除规则。用户可以编写他们一直以来使用的相同类型的规则，除了他们可以在规则的主体中引用任何其他策略中定义的表。

规则禁止在规则头部使用策略名称来前缀表名。规则禁止跨理论递归。

1) 示例 policy1: p(x) :- policy2:q(x)

policy2: q(x) :- nova:servers(x)

2) 非示例：不要在规则头部包含策略名称 policy:p(x) :- q(x)

3) 非示例：不要跨策略递归 policy1: p(x) :- policy2:q(x)

policy2: q(x) :- policy1:p(x)

备选方案¶

我们已经在数据源表名上（例如 nova: 和 neutron:）以概念上的方式执行此操作。此提案只是将该想法推广化。

另一种方法是将所有内容放入单个理论中，并显式地使用定义它们的模块为所有表添加前缀。在实现上，我们正在执行此操作，但将策略保留在单独的数据结构中，以便它们可以利用不同的理论类型。

许多其他的模块系统可用，但这基本上是 Python 的模块系统。只要您有对其的引用，所有内容对所有内容都是可见的。

此提案不包括分层策略（在其他策略中定义的策略）。虽然这种模型对于基于文件的编程语言来说是合理的，但对于基于 RESTful API 的编程语言来说，它不太合理，因为它没有固有的结构。此提案仍然允许人们使用分层策略名称，例如 marketing:manager:alice，但该层次结构没有内置到语言中。

策略¶

使用策略 policy1 和 policy2 的示例。我们假设我们在 policy0 中编写以下规则。

error(vm) :-: nova:virtual_machine(vm), policy1:vm_property(vm), neutron:port(vm, src_ip), policy2:ip_bad(src_ip).

策略操作¶

无

数据源¶

无

数据模型影响¶

无。只是策略引擎实现中的一项更改。

REST API 影响¶

每个添加或更改的 API 方法都应具有以下内容

create_policy

描述：创建具有给定名称、缩写和类型的新的策略
方法：POST
正常的 http 响应代码：成功
HTTP 错误
** 冲突：策略已存在 ** 请求错误：类型不存在
URL: /v1/policy/
参数：name, abbreviation (用于跟踪), type (Nonrecursive, Materialized)

示例：curl -X PUT https://:1789/v1/policy -d ‘{“id”: “test_policy”, “description”: “a great policy”, “abbreviation”: “test”, “type”: “nonrecursive”}’

示例输出：{“id”: “test_policy”, “description”: “a great policy”, “abbreviation”: “test”, “type”: “nonrecursive”, “owner”: “alice”}’

delete_policy: 标准删除操作

示例：curl -X DELETE https://:1789/v1/policy/test_policy

安全影响¶

无

通知影响¶

无

其他最终用户影响¶

用户在编写规则时将与其他策略交互。

性能影响¶

无

其他部署者影响¶

无

开发者影响¶

无

实现¶

负责人¶

主要负责人: thinrichs@vmware.com

工作项¶

将 create_policy/delete_policy 添加到 congress/policy/policy.py:Runtime。create_policy 的参数应包括 name/abbr/type，其中 type 为 NonrecursiveRuleTheory 或 MaterializedViewTheory。
将 compile.atom 更改为单独的 ‘module’ 字段和 ‘table’ 字段，以避免重复解析表名。如果不存在，则 ‘module’ 字段为 None。
修改 top_down_eval，以便在搜索的每个点，它都会跳转到定义该表的策略（或者如果 ‘module’ 为 None，则停留在当前策略中）。
确保跨理论没有无限循环。我们需要检查由跨越策略边界的规则获得的图是非递归的；我们可以忽略不跨越策略边界的规则。
可以保留 ‘includes’ 功能用于内部实现。不需要将其用于上述更改。
通过 API 和 CLI 暴露此功能

依赖项¶

无

测试¶

单元测试，包括正向测试和负向测试。

正向¶

1) 测试 1 policy1: p(x) :- policy2:q(x)

policy2: q(1) q(2)

查询：policy1:p(x) 产生 {p(1), p(2)}

2) 测试 2 policy1: p(x) :- policy2:q(x) r(1) r(2)

policy2 q(x) :- policy1:r(x)

查询：policy1:p(x) 产生 {p(1), p(2)}

3) 测试 3 (命名空间分离) policy1: p(x) :- policy2:q(x) q(1) q(2)

policy2 q(3) q(4)

查询：policy1:p(x) 产生 {p(3), p(4)}

负向¶