summaryrefslogtreecommitdiffstats
path: root/docs/design/introduction.rst
diff options
context:
space:
mode:
Diffstat (limited to 'docs/design/introduction.rst')
-rw-r--r--docs/design/introduction.rst81
1 files changed, 50 insertions, 31 deletions
diff --git a/docs/design/introduction.rst b/docs/design/introduction.rst
index a7cbb02..676adab 100644
--- a/docs/design/introduction.rst
+++ b/docs/design/introduction.rst
@@ -9,27 +9,29 @@ Introduction
.. NOTE::
This is the working documentation for the Copper project.
-The `OPNFV Copper <https://wiki.opnfv.org/copper>`_ project aims to help ensure that virtualized infrastructure
-deployments comply with goals of the VNF designer/user, e.g. re affinity and partitioning (e.g. per regulation,
-control/user plane separation, cost...).
-This is a "requirements" project with initial goal to assess "off the shelf" basic OPNFV platform support for policy
-management, using existing open source projects such as OpenStack Congress and OpenDaylight Group-Based Policy (GBP).
-The project will assess what policy-related features are currently supported through research into the related projects
-in OpenStack and ODL, and testing of integrated vanilla distributions of those and other dependent open source projects
-in the OPNFV's NFVI platform scope.
-
-Configuration Policy
---------------------
-
-As focused on by Copper, configuration policy helps ensure that the NFV service environment meets the requirements of
-the variety of stakeholders which will provide or use NFV platforms.
+The `OPNFV Copper <https://wiki.opnfv.org/copper>`_ project aims to help ensure
+that virtualized infrastructure and application deployments comply with goals of
+the NFV service provider or the VNF designer/user.
+
+This is the second ("Colorado") release of the Copper project. The documenation
+provided here focuses on the overall goals of the Copper project, and the
+specific features supported in the Colorado release.
+
+Overall Goals for Configuration Policy
+--------------------------------------
+
+As focused on by Copper, configuration policy helps ensure that the NFV service
+environment meets the requirements of the variety of stakeholders which will
+provide or use NFV platforms.
+
These requirements can be expressed as an *intent* of the stakeholder,
in specific terms or more abstractly, but at the highest level they express:
* what I want
* what I don't want
-Using road-based transportation as an analogy, some examples of this are shown below.
+Using road-based transportation as an analogy, some examples of this are shown
+below.
.. list-table:: Configuration Intent Example
:widths: 10 45 45
@@ -48,12 +50,17 @@ Using road-based transportation as an analogy, some examples of this are shown b
- shoulder warning strips, center media barriers
- speeding, tractors on the freeway
-According to their role, service providers may apply more specific configuration requirements than users,
-since service providers are more likely to be managing specific types of infrastructure capabilities.
+According to their role, service providers may apply more specific configuration
+requirements than users, since service providers are more likely to be managing
+specific types of infrastructure capabilities.
+
Developers and users may also express their requirements more specifically,
based upon the type of application or how the user intends to use it.
-For users, a high-level intent can be also translated into a more or less specific configuration capability
-by the service provider, taking into consideration aspects such as the type of application or its constraints.
+
+For users, a high-level intent can be also translated into a more or less specific
+configuration capability by the service provider, taking into consideration
+aspects such as the type of application or its constraints.
+
Examples of such translation are:
.. list-table:: Intent Translation into Configuration Capability
@@ -77,17 +84,29 @@ Examples of such translation are:
* - resource reclamation
- low-usage monitoring
-Although such intent to capability translation is conceptually useful, it is unclear how it can address the variety of
-aspects that may affect the choice of an applicable configuration capability.
-For that reason, the Copper project will initially focus on more specific configuration requirements as fulfilled by
-specific configuration capabilities, and how those requirements and capabilities are expressed in VNF and service
+Although such intent to capability translation is conceptually useful, it is
+unclear how it can address the variety of aspects that may affect the choice of
+an applicable configuration capability.
+
+For that reason, the Copper project will initially focus on more specific
+configuration requirements as fulfilled by specific configuration capabilities,
+and how those requirements and capabilities are expressed in VNF and service
design and packaging, or as generic poicies for the NFVI.
-Release 1 Scope
----------------
-OPNFV Brahmaputra will be the initial OPNFV release for Copper, with the goals:
- * Add the OpenStack Congress service to OPNFV, through at least one installer project
- * If possible, add Congress support to the OPNFV CI/CD pipeline for all Genesis project installers
- (Apex, Fuel, JOID, Compass)
- * Integrate Congress tests into Functest and develop additional use case tests for post-OPNFV-install
- * Extend with other OpenStack components for testing, as time permits
+Copper Release 1 Scope
+----------------------
+OPNFV Brahmaputra was the initial OPNFV release for Copper, and achieved the
+goals:
+ * Add the OpenStack Congress service to OPNFV, through at least one installer
+project, through post-install configuration.
+ * Provide basis tests scripts and tools to exercise the Congress service
+
+Copper Release 2 Scope
+----------------------
+OPNFV Colorado includes the additional features:
+ * Congress support in the the OPNFV CI/CD pipeline for the JOID and Apex
+installers, through the following projects being upstreamed to OpenStack:
+ * For JOID, a JuJu Charm for Congress
+ * For Apex, a Puppet Module for Congress
+ * Congress use case tests integrated into Functest and as manual tests
+ * Further enhancements of Congress test tools