summaryrefslogtreecommitdiffstats
path: root/networking-odl/doc/source/specs
diff options
context:
space:
mode:
Diffstat (limited to 'networking-odl/doc/source/specs')
-rw-r--r--networking-odl/doc/source/specs/journal-recovery.rst152
-rw-r--r--networking-odl/doc/source/specs/qos-driver.rst104
-rw-r--r--networking-odl/doc/source/specs/sfc-driver.rst139
3 files changed, 395 insertions, 0 deletions
diff --git a/networking-odl/doc/source/specs/journal-recovery.rst b/networking-odl/doc/source/specs/journal-recovery.rst
new file mode 100644
index 0000000..1132485
--- /dev/null
+++ b/networking-odl/doc/source/specs/journal-recovery.rst
@@ -0,0 +1,152 @@
+..
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
+ License.
+
+ http://creativecommons.org/licenses/by/3.0/legalcode
+
+================
+Journal Recovery
+================
+
+https://blueprints.launchpad.net/networking-odl/+spec/journal-recovery
+
+Journal entries in the failed state need to be handled somehow. This spec will
+try to address the issue and propose a solution.
+
+Problem Description
+===================
+
+Currently there is no handling for Journal entries that reach the failed state.
+A journal entry can reach the failed state for several reasons, some of which
+are:
+
+* Reached maximum failed attempts for retrying the operation.
+
+* Inconsistency between ODL and the Neutron DB.
+
+ * For example: An update fails because the resource doesn't exist in ODL.
+
+* Bugs that can lead to failure to sync up.
+
+These entries will be left in the journal table forever which is a bit wasteful
+since they take up some space on the DB storage and also affect the performance
+of the journal table.
+Albeit each entry has a negligble effect on it's own, the impact of a large
+number of such entries can become quite significant.
+
+Proposed Change
+===============
+
+A "journal recovery" routine will run as part of the current journal
+maintenance process.
+This routine will scan the journal table for rows in the "failed" state and
+will try to sync the resource for that entry.
+
+The procedure can be best described by the following flow chart:
+
+asciiflow::
+
+ +-----------------+
+ | For each entry |
+ | in failed state |
+ +-------+---------+
+ |
+ +-------v--------+
+ | Query resource |
+ | on ODL (REST) |
+ +-----+-----+----+
+ | | +-----------+
+ Resource | | Determine |
+ exists +--Resource doesn't exist--> operation |
+ | | type |
+ +-----v-----+ +-----+-----+
+ | Determine | |
+ | operation | |
+ | type | |
+ +-----+-----+ |
+ | +------------+ |
+ +--Create------> Mark entry <--Delete--+
+ | | completed | |
+ | +----------^-+ Create/
+ | | Update
+ | | |
+ | +------------+ | +-----v-----+
+ +--Delete--> Mark entry | | | Determine |
+ | | pending | | | parent |
+ | +---------^--+ | | relation |
+ | | | +-----+-----+
+ +-----v------+ | | |
+ | Compare to +--Different--+ | |
+ | resource | | |
+ | in DB +--Same------------+ |
+ +------------+ |
+ |
+ +-------------------+ |
+ | Create entry for <-----Has no parent------+
+ | resource creation | |
+ +--------^----------+ Has a parent
+ | |
+ | +---------v-----+
+ +------Parent exists------+ Query parent |
+ | on ODL (REST) |
+ +---------+-----+
+ +------------------+ |
+ | Create entry for <---Parent doesn't exist--+
+ | parent creation |
+ +------------------+
+
+For every error during the process the entry will remain in failed state but
+the error shouldn't stop processing of further entries.
+
+
+The implementation could be done in two phases where the parent handling is
+done in a a second pahse.
+For the first phase if we detect an entry that is in failed for a create/update
+operation and the resource doesn't exist on ODL we create a new "create
+resource" journal entry for the resource.
+
+This propsal utilises the journal mechanism for it's operation while the only
+part that deviates from the standard mode of operation is when it queries ODL
+directly. This direct query has to be done to get ODL's representation of the
+resource.
+
+Performance Impact
+------------------
+
+The maintenance thread will have another task to handle. This can lead to
+longer processing time and even cause the thread to skip an iteration.
+This is not an issue since the maintenance thread runs in parallel and doesn't
+directly impact the responsiveness of the system.
+
+Since most operations here involve I/O then CPU probably won't be impacted.
+
+Network traffic would be impacted slightly since we will attempt to fetch the
+resource each time from ODL and we might attempt to fetch it's parent.
+This is however negligble as we do this only for failed entries, which are
+expected to appear rarely.
+
+
+Alternatives
+------------
+
+The partial sync process could make this process obsolete (along with full
+sync), but it's a far more complicated and problematic process.
+It's better to start with this process which is more lightweight and doable
+and consider partial sync in the future.
+
+
+Assignee(s)
+===========
+
+Primary assignee:
+ mkolesni <mkolesni@redhat.com>
+
+Other contributors:
+ None
+
+
+References
+==========
+
+https://goo.gl/IOMpzJ
+
diff --git a/networking-odl/doc/source/specs/qos-driver.rst b/networking-odl/doc/source/specs/qos-driver.rst
new file mode 100644
index 0000000..d2faad1
--- /dev/null
+++ b/networking-odl/doc/source/specs/qos-driver.rst
@@ -0,0 +1,104 @@
+==========================================
+Quality of Service Driver for OpenDaylight
+==========================================
+
+This spec describes the plan to implement quality of service driver for
+OpenDaylight Controller.
+
+Problem Statement
+=================
+OpenStack networking project (neutron [1]) have a extension plugin implemented
+and which expose api for quality of service that can be also be implemented by
+any backend networking service provider to support QoS. These APIs provide a
+way to integrate OpenStack Neutron QoS with any of the backend QoS providers.
+OpenDaylight will provide backend for existing functionalities in neutron-QoS.
+A notification driver is needed for integration of existing api in Openstack
+neutron for QoS with OpenDaylight backend.
+
+Proposed Change
+===============
+This change will introduce a new notification driver in networking-odl that
+will take CRUD requests data for QoS policies from OpenStack neutron and notify
+the OpenDaylight controller about the respective operation.
+
+Detailed Design
+===============
+To enable the formal end to end integration between OpenStack QoS and
+OpenDaylight requires an networking-odl QoS notification driver. QoS driver
+will act as a shim layer between OpenStack and OpenDaylight that will carry
+out following task:
+
+#. After getting QoS policy request data from neutron, It will log a operation
+ request in opendaylightjournal table.
+
+#. The operation will be picked from opendaylightjournal table and a rest call
+ for notifying OpenDaylight server will be prepared and sent.
+
+#. This request will processed by neutron northbound in OpenDaylight.
+The OpenDaylight neutron northbound project. These models will be based
+on the existing neutron qos plugin APIs.
+
+QoS providers in OpenDaylight can listen to these OpenDaylight Neutron
+Northbound QoS models and translate it to their specific yang models for QoS.
+The following diagram shows the high level integration between OpenStack and
+the OpenDaylight QoS provider::
+
+ +---------------------------------------------+
+ | OpenStack Network Server (neutron qos) |
+ | |
+ | +---------------------+ |
+ | | networking-odl | |
+ | | | |
+ | | +---------------| |
+ | | | Notification | |
+ | | | driver QoS | |
+ +----------------------|----------------------+
+ |
+ | Rest Communication
+ |
+ OpenDaylight Controller |
+ +-----------------------|------------+
+ | +----------V----+ |
+ | ODL | QoS Yang Model| |
+ | Northbound | | |
+ | (neutron) +---------------+ |
+ | | |
+ | | |
+ | ODL +----V----+ |
+ | Southbound | QoS | |
+ | (neutron) +---------+ |
+ +-----------------|------------------+
+ |
+ |
+ +------------------------------------+
+ | Network/OVS |
+ | |
+ +------------------------------------+
+
+In the above diagram, the OpenDaylight components are shown just to understand
+the overall architecture, but it's out of scope of this spec's work items.
+This spec will only track progress related to networking-odl notification QoS
+driver work.
+
+Dependencies
+============
+It has a dependency on OpenDaylight Neutron Northbound QoS yang models, but
+that is out of scope of this spec.
+
+Impact
+======
+None
+
+Assignee(s)
+===========
+
+Following developers will be the initial contributor to the driver, but we
+will be happy to have more contributor on board.
+
+* Manjeet Singh Bhatia (manjeet.s.bhatia@intel.com, irc: manjeets)
+
+References
+==========
+
+[1] http://docs.openstack.org/developer/neutron/devref/quality_of_service.html
+[2] https://wiki.opendaylight.org/view/NeutronNorthbound:Main
diff --git a/networking-odl/doc/source/specs/sfc-driver.rst b/networking-odl/doc/source/specs/sfc-driver.rst
new file mode 100644
index 0000000..388b2c1
--- /dev/null
+++ b/networking-odl/doc/source/specs/sfc-driver.rst
@@ -0,0 +1,139 @@
+=================================================
+Service Function Chaining Driver for OpenDaylight
+=================================================
+
+This spec describes the plan to implement OpenStack networking-sfc[1] driver
+for OpenDaylight Controller.
+
+Problem Statement
+===================
+OpenStack SFC project (networking-sfc [1]) exposes generic APIs[2] for Service
+Function Chaining (SFC) that can be implemented by any backend networking
+service provider to support SFC. These APIs provide a way to integrate
+OpenStack SFC with any of the backend SFC providers. OpenDaylight SFC project
+provides a very mature implementation of SFC [3], but currently there is no
+formal integration mechanism present to consume OpenDaylight as an SFC provider
+for networking-sfc.
+
+Recently Tacker project [4] has been approved as an official project in
+OpenStack, that opens many possibilities to realize the NFV use cases (e.g SFC)
+using OpenStack as a platform. Providing a formal end to end integration
+between OpenStack and OpenDaylight for SFC use case will help NFV users
+leverage OpenStack, Tacker and OpenDaylight as a solution. A POC for this
+integration work has already been implemented [5][6] by Tim Rozet, but in
+this POC work, Tacker directly communicates to OpenDaylight SFC & classifier
+providers and not through OpenStack SFC APIs (networking-sfc).
+
+Proposed Change
+===============
+Implementation of this spec will introduce a networking-sfc[1] driver for
+OpenDaylight Controller in networking-odl project that will pass through
+the networking-sfc API's call to the OpenDaylight Controller.
+
+Detailed Design
+===============
+To enable the formal end to end integration between OpenStack SFC and
+OpenDaylight requires an SFC driver for OpenDaylight. ODL SFC driver will
+act as a shim layer between OpenStack and OpenDaylight that will carry out
+following two main tasks:
+
+* Translation of OpenStack SFC Classifier API to ODL SFC classifier yang
+ models**.
+
+* Translation of OpenStack SFC API's to OpenDaylight Neutron Northbound
+ SFC models** [8].
+
+** This work is not yet done, but the OpenDaylight neutron northbound project
+needs to come up with yang models for SFC classification/chain. These models
+will be based on the existing networking-sfc APIs. This work is out of scope
+of networking-odl work and will be collaborated in the scope of OpenDaylight
+Neutron Northbound project.
+
+SFC providers (E.g Net-Virt, GBP, SFC ) in OpenDaylight can listen to these
+OpenDaylight Neutron Northbound SFC models and translate it to their specific
+yang models for classification/sfc. The following diagram shows the high level
+integration between OpenStack and the OpenDaylight SFC provider::
+
+ +---------------------------------------------+
+ | OpenStack Network Server (networking-sfc) |
+ | +-------------------+ |
+ | | networking-odl | |
+ | | SFC Driver | |
+ | +-------------------+ |
+ +----------------------|----------------------+
+ | REST Communication
+ |
+ -----------------------
+ OpenDaylight Controller | |
+ +-----------------------|-----------------------|---------------+
+ | +----------v----+ +---v---+ |
+ | Neutron | SFC Classifier| |SFC | Neutron |
+ | Northbound | Models | |Models | Northbound|
+ | Project +---------------+ +-------+ Project |
+ | / \ | |
+ | / \ | |
+ | / \ | |
+ | +-----V--+ +---V----+ +---V---+ |
+ | |Net-Virt| ... | GBP | | SFC | ... |
+ | +---------+ +--------+ +-------+ |
+ +-----------|----------------|------------------|---------------+
+ | | |
+ | | |
+ +-----------V----------------V------------------V---------------+
+ | Network/OVS |
+ | |
+ +---------------------------------------------------------------+
+
+In the above architecture, the opendaylight components are shown just to
+understand the overall architecture, but it's out of scope of this spec's
+work items. This spec will only track progress related to networking-odl
+OpenStack sfc driver work.
+
+Given that OpenStack SFC APIs are port-pair based API's and OpenDaylight SFC
+API's are based on IETF SFC yang models[8], there might be situations where
+translation might requires API enhancement from OpenStack SFC. Networking SFC
+team is open for these new enhancement requirements given that they are generic
+enough to be leveraged by other backend SFC providers[9]. This work will be
+leveraging the POC work done by Tim [10] to come up with the first version of
+SFC driver.
+
+Dependencies
+============
+It has a dependency on OpenDaylight Neutron Northbound SFC classifier and chain
+yang models, but that is out of scope of this spec.
+
+Impact
+======
+None
+
+Assignee(s)
+===========
+
+Following developers will be the initial contributor to the driver, but we will
+be happy to have more contributor on board.
+
+* Anil Vishnoi (vishnoianil@gmail.com, irc: vishnoianil)
+* Tim Rozet (trozet@redhat.com, irc: trozet)
+
+References
+==========
+
+[1] http://docs.openstack.org/developer/networking-sfc/
+
+[2] https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst
+
+[3] https://wiki.opendaylight.org/view/Service_Function_Chaining:Main
+
+[4] https://wiki.openstack.org/wiki/Tacker
+
+[5] https://github.com/trozet/tacker/tree/SFC_brahmaputra/tacker/sfc
+
+[6] https://github.com/trozet/tacker/tree/SFC_brahmaputra/tacker/sfc_classifier
+
+[7] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-05
+
+[8] https://wiki.opendaylight.org/view/NeutronNorthbound:Main
+
+[9] http://eavesdrop.openstack.org/meetings/service_chaining/2016/service_chaining.2016-03-31-17.00.log.html
+
+[10] https://github.com/trozet/tacker/blob/SFC_brahmaputra/tacker/sfc/drivers/opendaylight.py