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, 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 |