项目指南¶
由于 Adjutant 项目的范围极其模糊，我们需要制定一些合理的指导方针来帮助我们定义哪些内容不属于该项目范畴，以及哪些内容应该或可以包含。
Adjutant 是一项服务，旨在让云提供商围绕某些操作构建工作流，或围绕 OpenStack 中现有的事物构建更小的 API。甚至可以构建与 OpenStack 集成的 API，但在外部系统中执行操作。
最终，Adjutant 是一个 Django 项目，具有一些限制，并且功能集系统可能暴露了过多的额外功能，这些功能可以添加。我们计划削减其中一些功能，并明确定义一些限制，但即使有了计划中的限制，该框架仍然会非常灵活。
功能是否应该成为核心部分¶
Adjutant 的核心主要分为两部分。第一部分是底层的 workflow 系统、相关的 API 以及通知。第二部分是提供商可配置的 API。随着我们尝试将 workflow 层与将一个任务链接到视图区分开来，这种分离将进一步加强。
任何对任务 workflow 框架以及相关的 API 和通知系统有用的改进，都始终对核心有用。作为这部分内容，我们包括，并计划继续添加，一系列常用的操作和任务。对于这些内容，我们需要明确哪些应该成为核心部分。
该操作是否更适合作为 OpenStack 中现有服务中的一个功能？如果是这样，我们应该将其添加到那里，然后构建一个在 Adjutant 中调用此新 API 或功能的 action。
您想要添加的 action 是否对任何云提供商有用或潜在有用？如果过于具体，则不应将其添加到核心。
您想要添加的 action 是否与 Adjutant 本身或 OpenStack 之外的系统交互？如果是，则不应将其添加到核心。
该任务（一系列 action 的组合）是否已经在某种程度上存在于 OpenStack 中，或者更适合作为另一个 OpenStack 服务的特性？如果是这样，它不属于核心。
此外，我们还包含一系列常用的 API 视图，这些视图将某些底层任务作为 workflow 框架的一部分公开。这些也需要明确何时应该包含在核心中。这些主要是构建更小的 API 的一种方式，云用户可以使用这些 API 来消费，这些 API 在底层使用 Adjutant 的 workflow 框架。或者经常构建 API，这些 API 在现有的 OpenStack API 和功能周围提供有用的封装或补充逻辑。
您正在构建的 API 是否更适合作为 OpenStack 中其他现有服务中的一个功能？如果是这样，它不属于 Adjutant 核心。
该 API 是否查询 Adjutant 或 OpenStack 之外的系统？或者依赖于也需要消费 Adjutant 或 OpenStack 之外系统的 action 或任务？
注意
如果一个 action、任务或 API 不适合核心，它可能适合于外部功能集，甚至可能是由核心团队维护的功能集。如果 OpenStack 中还没有我们可以快速构建在 Adjutant 中的功能，我们可以将其作为半官方的功能集来完成，并了解我们计划在 OpenStack 中正式提供该功能时弃用该功能集。此外，此过程允许提供商在运行不支持该功能的旧版本的 OpenStack 时，暴露该功能的变体，但 Adjutant 可以通过功能集机制来实现。这为我们提供了大量的灵活性，同时确保我们不会重复造轮子。
Adjutant 中逻辑类型的适当位置¶
在 Adjutant 中，系统的不同元素更适合于某些类型的逻辑，原因在于它们暴露的内容，或者给定区域的适当审计级别。
Actions 和 Tasks¶
Actions 和 Tasks（action 的集合）没有任何实际限制。一个 action 可以做任何事情，并且需要高度的灵活性。鉴于如此，它们应该理想情况下具有合理的验证机制，并且应该记录它们所做的事情，以便进行审计。
Pluggable APIs¶
在可插拔的 API 中，不应有任何更改 Adjutant 之外资源的逻辑。它们应该只更改 Adjutant 内部资源（例如取消任务），或者查询和返回数据。构建一个可以在多个 OpenStack 服务之间返回复杂查询的 API 很好，但是如果需要更改任何这些服务中的资源，则应始终通过触发底层的任务 workflow 来完成。这保持了逻辑的清晰，并且使更改可审计。
警告
任何违反上述规范的功能集作者将不受支持。我们可能会帮助并鼓励您迁移到使用底层的 workflow，但核心团队不会帮助您解决任何不在正确位置的逻辑问题。
