diff options
Diffstat (limited to 'networking-odl/doc/source/specs')
| -rw-r--r-- | networking-odl/doc/source/specs/journal-recovery.rst | 152 | ||||
| -rw-r--r-- | networking-odl/doc/source/specs/qos-driver.rst | 104 | ||||
| -rw-r--r-- | networking-odl/doc/source/specs/sfc-driver.rst | 139 |
3 files changed, 0 insertions, 395 deletions
diff --git a/networking-odl/doc/source/specs/journal-recovery.rst b/networking-odl/doc/source/specs/journal-recovery.rst deleted file mode 100644 index 1132485..0000000 --- a/networking-odl/doc/source/specs/journal-recovery.rst +++ /dev/null @@ -1,152 +0,0 @@ -.. - 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 deleted file mode 100644 index d2faad1..0000000 --- a/networking-odl/doc/source/specs/qos-driver.rst +++ /dev/null @@ -1,104 +0,0 @@ -========================================== -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 deleted file mode 100644 index 388b2c1..0000000 --- a/networking-odl/doc/source/specs/sfc-driver.rst +++ /dev/null @@ -1,139 +0,0 @@ -================================================= -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 |