Barbican/Discussion-Plugin-Design
目录
此wiki页面正在进行中，旨在让贡献者思考如何管理Barbican插件以及Juno版本及以后的工作流程。
此页面探讨了Barbican插件接口的设计概念。Barbican当前使用插件与硬件安全模块 (HSM) 等加密资源进行接口。此页面还讨论了插件方法如何适应计划添加到订单资源中的SSL证书生成和管理。
概述
下图描述了Barbican中的通用插件数据流。请注意“核心”Barbican功能（在主Barbican仓库中可用，代表为插件完成的工作）与“插件”功能之间的分离，以执行某种类型的工作，这可能包括与外部服务的交互。插件可以通过同步或异步过程调用，例如用于加密/解密/验证或用于订单处理。这些“插件”的源代码可能包含在Barbican代码库中，也可能不包含。
专注于Barbican Core，插件必须基于某些标准从多个潜在的实现插件中选择，例如第一个支持该功能的插件。插件选择将在后面的部分中讨论。
Barbican 必须随后向插件提供输入以完成其工作。如果插件在多次调用插件时是状态化的，那么Barbican应该代表插件存储此状态，并将此数据键入到流程实例，例如特定的订单流程。请注意，Barbican 还可以传递一个“控制反转”(IoC) 组件到插件，这将允许插件在不知道Barbican如何实现这些服务的情况下与Barbican服务（例如事件生成）交互。
当插件被调用时，插件执行其工作，这可能包括与外部服务交互。对于同步工作流（例如Barbican API处理），应尽快进行这些服务调用，因为响应返回给客户端将被阻止，直到它们完成为止。
一旦插件返回，Barbican Core 就可以持久化结果。如果需要，状态也可以持久化到Barbican Core数据存储中，以便后续插件调用（例如给定SSL证书的扩展工作流程处理）。Barbican Core还可以支持如果需要根据计划再次调用插件。
异步订单处理插件
概述部分详细介绍了Barbican插件流程。本节为异步订单处理流程添加更多详细信息，特别是对于涉及与认证机构 (CA) 交互的SSL证书生成。下图描述了Barbican Core worker进程通过RPC调用从oslo.messaging队列服务调用的异步处理。
对于SSL证书生成，可能有多个供应商插件可用，例如用于Dogtag或Symantec，因此订单的详细信息应包括使用哪个供应商进行选择标准，或者Barbican应支持指定默认供应商/插件。相同的供应商插件可用于验证输入（尤其是CSR所需的许多字段）以及用于异步worker端订单处理。
Barbican 然后检索与给定订单实例关联的任何状态，可能通过与订单记录一起存储的订单元数据信息。插件可以将此状态定义为键/值对，例如。由于相同的插件可能会多次为相同的订单实例调用，因此持久化的状态可能包括一个状态机状态名称，该名称指示供应商插件内使用哪个业务逻辑。如果订单实例需要“链接”到外部系统的订单引用（例如Symantec），则可以将其存储在元数据中（由插件确定）。
接下来，Barbican Core 必须提供IoC组件，以允许插件执行系统交互（例如数据库更新和事件通知），而无需直接访问这些关键核心组件。如图所示，一个IoC处理程序可以呈现特定的方法，例如'notify_ssl_cert_is_ready()'，这些方法由Barbican Core处理为开箱即用的简单日志消息，或者作为通过oslo incubator或Ceilometer发送的CADF消息，供外部系统在部署/公司特定的方式中消耗。另一个IoC处理程序可以“包装”数据模型操作，例如'generate_private_key()'，Barbican Core 将其实现为加密包中的生成/加密/存储操作。
可以调用订单处理插件，也许基于先前状态信息进行路由，例如用于SSL证书处理的状态机处理。插件可以响应一个状态，Barbican Core逻辑可以使用该状态来确定下一步该怎么做……例如，“完成”可能表示订单处理已完成，“继续”可能意味着将插件状态与订单一起持久化，以便将来的插件调用（例如通过从CA调用的计划批量更新），而“重试”可能意味着在将来的某个时间再次调用插件以重试操作。
计划和批量处理
到目前为止的讨论集中在为给定工作流程或订单实例同步和异步调用插件上，但某些过程可能需要跨多个实例进行批量处理。例如，SSL证书处理可能涉及根据计划从CA请求状态。该状态可能是多个SSL证书订单状态的批处理，因此Barbican需要遍历这些订单状态并单独为它们调用插件任务。插件可以提供一个Barbican Core可以根据计划调用的批处理方法，并传递一个插件为每个订单实例看到的批处理中调用的回调函数。Barbican Core 将通过将插件RPC任务排队到worker节点来实施回调。
为了实施计划过程，Barbican可以使用Nova方法，该方法使用oslo-incubator的periodic_tasks 注解来标记应进行计划的Service方法。它在底层使用Eventlet greenpools。目前worker服务器扩展了olso的Service，因此它们是放置计划过程的逻辑位置。但是，这里的一个问题是，为了可靠性，每个worker都应该能够安排任务，例如上述SSL批量状态任务。如果这些单独的计划任务反过来正在排队单个订单更新任务，那么可能多个worker正在处理相同的订单实例。
插件源代码组织
“Barbican Core”的源代码位于stackforge/barbican 仓库中，包括支持上述图表左侧的逻辑，以及定义图中中间插件交互的抽象基类。Core 还应始终包含简单的示例和独立插件实现，这些插件在本地安装上默认启用。它们不应需要网络访问才能运行，并且应该经过充分的单元测试，并为新插件的开发人员提供良好的示例。
然而，除了这些简单的默认插件之外，如何管理特定插件实现源代码并不明显。一方面，将具有特定插件实现的源代码与Core源代码捆绑在一起很方便，这些插件可能用于生产Barbican安装。例如，Barbican Core 当前包含基于PKCS11和Dogtag的加密插件。另一方面，这些插件通常依赖于OpenStack全局要求不包含的库，因此必须适应没有安装这些依赖项的开箱即用的部署。因此，彻底的单元测试更加困难（通过打补丁），代码逻辑也更复杂，需要处理缺少的导入。
另一种选择是为插件实现源代码创建单独的git仓库，并依赖于Barbican Core源代码，例如扩展抽象插件合同。这种方法将简化Barbican Core代码库，但需要集成多个仓库进行测试。它还需要机制来扩展Barbican以在打包时包含这些外部依赖项。这在下一节中探讨。
发现第三方插件
Barbican Core现在包含的捆绑加密插件实现（例如PKCS11和Dogtag），激活它们以供使用只需将它们的依赖项包含在部署的Python包或部署中，然后在/etc/barbican/barbican-api.conf 文件中启用它们。Stevedore 提供了加载这些插件并在运行时选择/使用它们的能力。
对于在Barbican Core 之外开发的插件，仍然可以使用Stevedore，并且除了安装非OpenStack依赖项和向 barbican-api.conf 添加配置项之外，还需要添加一个 setup.cfg 文件，该文件定义新的插件命名空间、别名和类路径。然后可以创建一个新的自定义部署包并安装。
另一种选择是使用类似于Heat项目资源发现的插件模块发现过程。Heat 定义了一个搜索新资源（以Python源代码文件形式）的文件夹位置，这些资源扩展了基础资源。可以使用类似的方法来发现插件实现。
