summaryrefslogtreecommitdiffstats
path: root/docs/development/requirements/requirements.rst
diff options
context:
space:
mode:
Diffstat (limited to 'docs/development/requirements/requirements.rst')
-rw-r--r--docs/development/requirements/requirements.rst135
1 files changed, 135 insertions, 0 deletions
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 <http://docs.openstack.org/developer/heat/template_guide/index.html>`_
+ feature, enabling a variety of VM aspects to be defined and managed by
+ Heat throughout the VM lifecycle, notably
+
+ * alarm handling (requires `Ceilometer <https://wiki.openstack.org/wiki/Ceilometer>`_)
+ * attached volumes (requires `Cinder <https://wiki.openstack.org/wiki/Cinder>`_)
+ * domain name assignment (requires `Designate <https://wiki.openstack.org/wiki/Designate>`_)
+ * images (requires `Glance <https://wiki.openstack.org/wiki/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 <http://docs.openstack.org/developer/keystone/>`_)
+ * shared storage (requires `Manila <https://wiki.openstack.org/wiki/Manila>`_)
+ * load balancing (requires `Neutron LBaaS <http://docs.openstack.org/admin-guide/networking.html>`_)
+ * firewalls (requires `Neutron FWaaS <http://docs.openstack.org/admin-guide/networking.html>`_)
+ * 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 <https://wiki.openstack.org/wiki/Sahara>`_)
+ * DBaaS (requires `Trove <http://docs.openstack.org/developer/trove/>`_)
+ * "multi-tenant cloud messaging and notification service" (requires
+ `Zaqar <http://docs.openstack.org/developer/zaqar/>`_)
+
+ * `OpenStack Group-Based Policy <https://wiki.openstack.org/wiki/GroupBasedPolicy>`_
+
+ * API-based grouping of endpoints with associated contractual expectations for data flow processing and service chaining
+
+ * `OpenStack Tacker <https://wiki.openstack.org/wiki/Tacker>`_
+
+ * "a fully functional ETSI MANO based general purpose NFV Orchestrator and VNF Manager for OpenStack"
+
+ * `OpenDaylight Group-Based Policy <https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)>`_
+
+ * model-based grouping of endpoints with associated contractual expectations for data flow processing
+
+ * `OpenDaylight Service Function Chaining (SFC) <https://wiki.opendaylight.org/view/Service_Function_Chaining:Main>`_
+
+ * 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 <https://puppetlabs.com/puppet/puppet-open-source>`_
+ * `Chef <https://www.chef.io/chef/>`_
+ * `Ansible <http://docs.ansible.com/ansible/index.html>`_
+ * `Salt <http://saltstack.com/community/>`_
+
+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 <http://docs.openstack.org/developer/congress/index.html>`_ 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 <https://wiki.openstack.org/wiki/Telemetry#Aodh>`_
+ provides means to trigger alarms upon a wide variety of conditions derived
+ from its monitored OpenStack analytics.
+ * `Nagios <https://www.nagios.org/#/>`_ "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.