From 1c2509b3e5c36b1393c638a172a165742effc47f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Douglas=20Mendiz=C3=A1bal?= Date: Tue, 11 Aug 2015 22:48:08 -0500 Subject: [PATCH] Introduce the concept of plugin status As discussed in the liberty midcycle sprint, plugin support will be described by using a status. Change-Id: I242f4137c11c36f52c17588688fb22f3dd620240 --- doc/source/plugin/index.rst | 47 +++++++++++++++++++++++++++++++++++-- 1 file changed, 45 insertions(+), 2 deletions(-) diff --git a/doc/source/plugin/index.rst b/doc/source/plugin/index.rst index ca5849cb3..5142e12fd 100644 --- a/doc/source/plugin/index.rst +++ b/doc/source/plugin/index.rst @@ -1,15 +1,58 @@ +========================= Plugin Developers Guide ========================= This guide describes how to develop custom plugins for use by Barbican. While Barbican provides useful plugin implementations, some OpenStack operators may -require customized implementations, perhaps to interact with a an existing +require customized implementations, perhaps to interact with an existing corporate database or service. This approach also gives flexibility to operators of OpenStack clouds by allowing them to choose the right implementation for their cloud. +Plugin Status +============= +A Barbican plugin may be considered ``stable``, ``experimental`` or +``out-of-tree``. + +* A *stable* status indicates that the plugin is fully supported by the + OpenStack Barbican Team +* An *experimental* status indicates that we intend to support the plugin, + but it may be missing features or may not be fully tested at the gate. + Plugins in this status may occasionally break. +* An *out-of-tree* status indicates that no formal support will be provided, + and the plugin may be removed in a future release. + +Graduation Process +------------------ +By default, new plugins proposed to be in-tree will be in the *experimental* +status. To be considered *stable* a plugin must meet the following +requirements: + +* 100% unit test coverage, including branch coverage. +* Gate job that executes the functional test suite against an instance of + Barbican configured to use the plugin. The gate may be a devstack gate, + or a third-party gate. +* Implement new features within one cycle after the new blueprint feature + is approved. + +Demotion Process +---------------- +Plugins should not stay in the *experimental* status for a long time. +Plugins that stay in *experimental* for more than **two** releases are +expected to move into *stable*, as described by the Graduation Process, or +move into *out-of-tree*. + +Plugins in the *stable* status may be deprecated by the team, and moved to +*out-of-tree*. + +Plugins that stay in the *out-of-tree* status for more than **two** releases +may be removed from the tree. + +Architecture +============ + Barbican's plugin architecture enables developers to create their own -implementations of features such as secret storage and generation, SSL +implementations of features such as secret storage and generation, X.509 certificate generation, and event handling. The plugin pattern used defines an abstract class, whose methods are invoked by Barbican logic (referred to as Barbican 'core' in this guide) in a particular sequence. Typically plugins do