diff options
Diffstat (limited to 'docs/design/introduction.rst')
| -rw-r--r-- | docs/design/introduction.rst | 31 |
1 files changed, 26 insertions, 5 deletions
diff --git a/docs/design/introduction.rst b/docs/design/introduction.rst index f82d47e..a7cbb02 100644 --- a/docs/design/introduction.rst +++ b/docs/design/introduction.rst @@ -9,12 +9,22 @@ 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. +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. These requirements can be expressed as an *intent* of the stakeholder, in specific terms or more abstractly, but at the highest level they express: +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 @@ -38,7 +48,13 @@ 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. 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. Examples of such translation are: +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. +Examples of such translation are: .. list-table:: Intent Translation into Configuration Capability :widths: 40 60 @@ -61,12 +77,17 @@ According to their role, service providers may apply more specific configuration * - 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 design and packaging, or as generic poicies for the NFVI. +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) + * 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 |