summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorblsaws <bryan.sullivan@att.com>2016-08-18 22:43:48 -0700
committerblsaws <bryan.sullivan@att.com>2016-08-18 23:03:24 -0700
commit10b1da200d506d82f6c936d4113df0ec2583cce8 (patch)
tree4e1c75845645a01151ec8f90a83f3c3dd30a89c1
parent816fc353daf07ffe8f2adc12d565c070fe4f3746 (diff)
Fix link issues
JIRA: COPPER-1 More issues... Change-Id: I0bf14d6e6b91c57fb8c132bee991d472ef8c8f31 Signed-off-by: blsaws <bryan.sullivan@att.com>
-rw-r--r--docs/design/introduction.rst4
-rw-r--r--docs/design/requirements.rst84
2 files changed, 44 insertions, 44 deletions
diff --git a/docs/design/introduction.rst b/docs/design/introduction.rst
index 676adab..378eda6 100644
--- a/docs/design/introduction.rst
+++ b/docs/design/introduction.rst
@@ -98,14 +98,14 @@ 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.
+ 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:
+ 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
diff --git a/docs/design/requirements.rst b/docs/design/requirements.rst
index a3f32d8..da2c280 100644
--- a/docs/design/requirements.rst
+++ b/docs/design/requirements.rst
@@ -2,6 +2,7 @@ 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,
@@ -13,39 +14,35 @@ 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
- <http://docs.openstack.org/openstack-ops/content/user_facing_images.html>`_
- feature, enabling "VM templates" to be defined for NFs, and referenced by
- name as a specific NF version to be used
- * the `flavor <http://docs.openstack.org/openstack-ops/content/flavors.html>`_
- feature, addressing basic compute and storage requirements, with
- extensibility for custom attributes
+
+ * the `image <http://docs.openstack.org/openstack-ops/content/user_facing_images.html>`_ feature, enabling "VM templates" to be defined for NFs,
+ and referenced by name as a specific NF version to be used
+ * the `flavor <http://docs.openstack.org/openstack-ops/content/flavors.html>`_ 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>`_
+
+ * 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>`_)
+
+ * 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"
+ * 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-cloud/content/section_lbaas-overview.html>`_)
+ `LBaaS <http://docs.openstack.org/admin-guide-cloud/content/section_lbaas-overview.html>`_)
* firewalls (requires Neutron
- `FWaaS
- <http://docs.openstack.org/admin-guide-cloud/content/install_neutron-fwaas-agent.html>`_)
+ `FWaaS <http://docs.openstack.org/admin-guide-cloud/content/install_neutron-fwaas-agent.html>`_)
* various Neutron-based network and security configuration items
* Nova flavors
* Nova server attributes including access control
@@ -55,24 +52,27 @@ include multiple ways in which resource requirements can be expressed and fulfil
* 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 `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
+
+ * "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>`_
@@ -89,6 +89,7 @@ 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
@@ -106,28 +107,27 @@ high-level required capabilities include:
Upstream projects already include multiple ways in which configuration conditions
can be monitored and responded to:
+
* OpenStack `Congress <https://wiki.openstack.org/wiki/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. See `Stackforge Congress Data Source
- Translators
- <https://github.com/stackforge/congress/tree/master/congress/datasources>`_,
- `congress.readthedocs.org
- <http://congress.readthedocs.org/en/latest/cloudservices.html#drivers>`_,
+ the new monitored state information. See
+ `Stackforge Congress Data Source Translators <https://github.com/stackforge/congress/tree/master/congress/datasources>`_,
+ `congress.readthedocs.org <http://congress.readthedocs.org/en/latest/cloudservices.html#drivers>`_,
and the `Congress specs <https://github.com/stackforge/congress-specs>`_ for
more info.
* OpenStack `Ceilometer <https://wiki.openstack.org/wiki/Ceilometer>`_
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".
+ * `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