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 <aimeeu.opensource@gmail.com>

1 files changed, 0 insertions, 135 deletions

diff --git a/docs/design/requirements.rst b/docs/design/requirements.rst
deleted file mode 100644
index 87894cf..0000000
--- a/docs/design/requirements.rst
+++ /dev/null
@@ -1,135 +0,0 @@
-.. 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.