From 572ce78c886cf49bd617a2ff3d96491b22a66f88 Mon Sep 17 00:00:00 2001 From: Aimee Ukasick Date: Tue, 7 Feb 2017 13:23:37 -0600 Subject: Updated to use new docs structure WIP JIRA: COPPER-1 WIP - not sure how to fill in the docs/release/scenarios section Change-Id: I8684e4647e7b943ca05dc77131a54338ff932b78 Signed-off-by: Aimee Ukasick --- docs/development/requirements/requirements.rst | 135 +++++++++++++++++++++++++ 1 file changed, 135 insertions(+) create mode 100644 docs/development/requirements/requirements.rst (limited to 'docs/development/requirements/requirements.rst') diff --git a/docs/development/requirements/requirements.rst b/docs/development/requirements/requirements.rst new file mode 100644 index 0000000..87894cf --- /dev/null +++ b/docs/development/requirements/requirements.rst @@ -0,0 +1,135 @@ +.. This work is licensed under a +.. Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) 2015-2017 AT&T Intellectual Property, Inc + +Requirements +============ +This section outlines general requirements for configuration policies, +per the two main aspects in the Copper project scope: + + * Ensuring resource requirements of VNFs and services are applied per VNF + designer, service, and tenant intent + * Ensuring that generic policies are not violated, + e.g. *networks connected to VMs must either be public or owned by the VM owner* + +Resource Requirements ++++++++++++++++++++++ +Resource requirements describe the characteristics of virtual resources (compute, +storage, network) that are needed for VNFs and services, and how those resources +should be managed over the lifecycle of a VNF/service. Upstream projects already +include multiple ways in which resource requirements can be expressed and fulfilled, e.g.: + + * OpenStack Nova + + * the Image feature, enabling "VM templates" to be defined for NFs and referenced by name as a specific NF version to be used + * the Flavor feature, addressing basic compute and storage requirements, with extensibility for custom attributes + + * OpenStack Heat + + * the `Heat Orchestration Template `_ + feature, enabling a variety of VM aspects to be defined and managed by + Heat throughout the VM lifecycle, notably + + * alarm handling (requires `Ceilometer `_) + * attached volumes (requires `Cinder `_) + * domain name assignment (requires `Designate `_) + * images (requires `Glance `_) + * autoscaling + * software configuration associated with VM lifecycle hooks (CREATE, + UPDATE, SUSPEND, RESUME, DELETE) + * wait conditions and signaling for sequencing orchestration steps + * orchestration service user management (requires + `Keystone `_) + * shared storage (requires `Manila `_) + * load balancing (requires `Neutron LBaaS `_) + * firewalls (requires `Neutron FWaaS `_) + * various Neutron-based network and security configuration items + * Nova flavors + * Nova server attributes including access control + * Nova server group affinity and anti-affinity + * "Data-intensive application clustering" (requires + `Sahara `_) + * DBaaS (requires `Trove `_) + * "multi-tenant cloud messaging and notification service" (requires + `Zaqar `_) + + * `OpenStack Group-Based Policy `_ + + * API-based grouping of endpoints with associated contractual expectations for data flow processing and service chaining + + * `OpenStack Tacker `_ + + * "a fully functional ETSI MANO based general purpose NFV Orchestrator and VNF Manager for OpenStack" + + * `OpenDaylight Group-Based Policy `_ + + * model-based grouping of endpoints with associated contractual expectations for data flow processing + + * `OpenDaylight Service Function Chaining (SFC) `_ + + * model-based management of "service chains" and the infrastucture that enables them + + * Additional projects that are commonly used for configuration management, + implemented as client-server frameworks using model-based, declarative, or + scripted configuration management data. + + * `Puppet `_ + * `Chef `_ + * `Ansible `_ + * `Salt `_ + +Generic Policy Requirements ++++++++++++++++++++++++++++ +Generic policy requirements address conditions related to resource state and +events which need to be monitored for, and optionally responded to or prevented. +These conditions are typically expected to be VNF/service-independent, as +VNF/service-dependent condition handling (e.g. scale in/out) are considered to +be addressed by VNFM/NFVO/VIM functions as described under Resource Requirements +or as FCAPS related functions. However the general capabilities below can be +applied to VNF/service-specific policy handling as well, or in particular to +invocation of VNF/service-specific management/orchestration actions. The +high-level required capabilities include: + + * Polled monitoring: Exposure of state via request-response APIs. + * Notifications: Exposure of state via pub-sub APIs. + * Realtime/near-realtime notifications: Notifications that occur in actual or + near realtime. + * Delegated policy: CRUD operations on policies that are distributed to + specific components for local handling, including one/more of monitoring, + violation reporting, and enforcement. + * Violation reporting: Reporting of conditions that represent a policy violation. + * Reactive enforcement: Enforcement actions taken in response to policy + violation events. + * Proactive enforcement: Enforcement actions taken in advance of policy + violation events, + e.g. blocking actions that could result in a policy violation. + * Compliance auditing: Periodic auditing of state against policies. + +Upstream projects already include multiple ways in which configuration conditions +can be monitored and responded to: + + * OpenStack `Congress `_ provides a + table-based mechanism for state monitoring and proactive/reactive policy + enforcement, including data obtained from internal databases of OpenStack + core and optional services. The Congress design approach is also extensible + to other VIMs (e.g. SDNCs) through development of data source drivers for + the new monitored state information. + * OpenStack `Aodh `_ + provides means to trigger alarms upon a wide variety of conditions derived + from its monitored OpenStack analytics. + * `Nagios `_ "offers complete monitoring and alerting for servers, switches, applications, and services". + +Requirements Validation Approach +++++++++++++++++++++++++++++++++ +The Copper project will assess the completeness of the upstream project solutions +for requirements in scope though a process of: + + * developing configuration policy use cases to focus solution assessment tests + * integrating the projects into the OPNFV platform for testing + * executing functional and performance tests for the solutions + * assessing overall requirements coverage and gaps in the most complete + upstream solutions + +Depending upon the priority of discovered gaps, new requirements will be +submitted to upstream projects for the next available release cycle. -- cgit 1.2.3-korg