Blueprint for OpenDaylight integration in OSA
This blueprint describes the work needed to deploy the OpenDaylight SDN controller as a neutron backend by using openstack-ansible. The document covers the implications of installing OpenDaylight, its configuration, and the connection between OpenDaylight and OpenvSwitch. Several references are provided for further information. Change-Id: I8b2c85c2a6b06d9a4ddcc568ee80ac2a0800fe7c Signed-off-by: Juan Vidal <juan.vidal.allende@ericsson.com>
This commit is contained in:
Juan Vidal
parent
a3cbeb649b
commit
9b50f03576
196
specs/pike/opendaylight.rst
Normal file
196
specs/pike/opendaylight.rst
Normal file
@ -0,0 +1,196 @@
|
||||
Integration of OpenDaylight SDN controller with Neutron
|
||||
#######################################################
|
||||
:date: 2017-06-08 11:00
|
||||
:tags: opendaylight, neutron, SDN, openvswitch
|
||||
|
||||
Blueprint on Launchpad:
|
||||
|
||||
* https://blueprints.launchpad.net/openstack-ansible/+spec/opendaylight
|
||||
|
||||
This spec introduces the work required to have the OpenDaylight (ODL) SDN
|
||||
controller deployed as a Neutron backend, using networking-odl ML2
|
||||
mechanism driver to connect to Neutron.
|
||||
|
||||
This spec also covers the connection of OpenvSwitch (OvS) to OpenDaylight.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
OpenStack networking (Neutron) uses a modular approach that allows different
|
||||
backends to be used, by means of mechanism drivers. Although Neutron can handle
|
||||
simple deployments, more advanced networking capabilities are better addressed
|
||||
with an advanced SDN controller, such as OpenDaylight.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
The proposed change consists on using the existing OpenDaylight Ansible role
|
||||
and optionally deploying it along with Neutron. The connection of OpenDaylight
|
||||
and Neutron is done by using the networking-odl ML2 mechanism driver, and
|
||||
configuring Neutron to use it.
|
||||
|
||||
After OpenDaylight and networking-odl are installed, some configuration is
|
||||
required in ``ml2.ini`` file to instruct Neutron to use the mechanism driver,
|
||||
as well as setup OpenDaylight's endpoint and credentials.
|
||||
|
||||
Final step consists on connecting the traffic forwarding elements with the
|
||||
OpenDaylight controller. This spec will use OpenvSwitch for this task. Also,
|
||||
neutron-openvswitch-agent needs to be stopped and disabled, as OpenDaylight
|
||||
is the responsible for data plane management.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
There are other networking backend for Neutron already available with
|
||||
Openstack-Ansible, namely Calico (https://www.projectcalico.org/tag/openstack/)
|
||||
and DragonFlow (https://wiki.openstack.org/wiki/Dragonflow). These backends
|
||||
are optionally deployed depending on the ML2 configuration that is passed to
|
||||
``os_neutron`` Ansible role.
|
||||
|
||||
Playbook/Role impact
|
||||
--------------------
|
||||
|
||||
The os_neutron role will be modified to optionally deploy OpenDaylight. The
|
||||
proposal is to use the same approach as DragonFlow: when the
|
||||
``neutron_plugin_type`` variable is set to ``ml2.opendaylight``, OpenDaylight
|
||||
would be used as Neutron backend. There will be a new taskfile,
|
||||
``neutron_opendaylight_setup.yml``, which would be included in os_neutron's
|
||||
playbook when the above condition is fulfilled.
|
||||
|
||||
The OpenvSwitch scenario would be leveraged to work with OpenDaylight, being
|
||||
OvS the only switch supported in the first release.
|
||||
|
||||
Upgrade impact
|
||||
--------------
|
||||
|
||||
This is the first implementation of OpenDaylight with Openstack-Ansible, so no
|
||||
upgrade concerns yet.
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
Networking-odl configuration requires the setup of a username and password for
|
||||
northbound auhentication towards OpenDaylight. The deployer should be able to
|
||||
configure those credentials.
|
||||
|
||||
Communication between the controller and the switches will not be secured by
|
||||
default. Using TLS to secure the communications is considered a stretch goal,
|
||||
and deployers need to consider this security implication, specially in
|
||||
production environments. For more information on secure communications between
|
||||
OpenDaylight and OpenvSwitch, see the `References`_.
|
||||
|
||||
Performance impact
|
||||
------------------
|
||||
|
||||
For those choosing to opt-in this deployment method, some extra packages need
|
||||
to be installed on the system, which would make installation last a bit longer.
|
||||
|
||||
Extra resources are needed to run the OpenDaylight SDN controller on
|
||||
the system as well. However, performance in Neutron API calls should be
|
||||
minimum.
|
||||
|
||||
End user impact
|
||||
---------------
|
||||
|
||||
End users would have a new networking API available through OpenDaylight. This
|
||||
would enable them to create advanced networking scenarios (e.g. Service
|
||||
Function Chaining). This will require some documentation with troubleshooting
|
||||
steps to verify that OpenDaylight is working properly, as well as pointers
|
||||
to OpenDaylight's official documentation.
|
||||
|
||||
No changes to Horizon or other OpenStack components are expected.
|
||||
|
||||
Deployer impact
|
||||
---------------
|
||||
|
||||
New artifacts are being deployed, namely the Karaf runtime for OpenDaylight,
|
||||
and the networking-odl pip package. OpenDaylight requires around 2.5G of RAM
|
||||
to work properly, with OpenStack, that would need to be considered when
|
||||
dimensioning the host where it will run.
|
||||
|
||||
Also deployers need to ensure that OpenvSwitch is deployed in all networking
|
||||
nodes, namely compute hosts and hosts where neutron agents are running.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
Developer impact is very low, all tasks for OpenDaylight deployment will be
|
||||
optional and can be ignored when extending or modifying Neutron role.
|
||||
|
||||
Dependencies
|
||||
------------
|
||||
|
||||
There are no dependencies
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
Juan Vidal (jvidal)
|
||||
|
||||
Other contributors:
|
||||
Fatih Degirmenci (fdegir)
|
||||
Daniel Farrell (dfarrell07)
|
||||
|
||||
Work items
|
||||
----------
|
||||
|
||||
1. Install OpenDaylight SDN controller
|
||||
2. Configure Neutron to use OpenDaylight
|
||||
3. Deploy and configure OpenvSwitch to work with OpenDaylight
|
||||
4. Set OpenDaylight as OpenvSwitch manager
|
||||
5. Create a new test and verify that it passes
|
||||
6. Document the new scenario
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
As a replacement of Neutron backend, this new scenario should provide the same
|
||||
capabilities of existing backends, so existing tests should be run.
|
||||
|
||||
A test specific for OpenDaylight can also be implemented, in the same way as
|
||||
there are currently tests for Calico or DragonFlow.
|
||||
|
||||
Documentation impact
|
||||
====================
|
||||
|
||||
The new scenario *OpenDaylight+OpenvSwitch* should be documented, explaining
|
||||
the configuration parameters required to deploy it.
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
Deploying OpenDaylight using Ansible:
|
||||
|
||||
* https://wiki.opendaylight.org/view/Deployment#Ansible_Role
|
||||
|
||||
Ansible role for OpenDaylight:
|
||||
|
||||
* https://git.opendaylight.org/gerrit/p/integration/packaging/ansible-opendaylight.git
|
||||
|
||||
Setting up OpenDaylight on OpenStack:
|
||||
|
||||
* https://wiki.opendaylight.org/view/OpenStack_and_OpenDaylight
|
||||
|
||||
Networking-odl mechanism driver:
|
||||
|
||||
* https://github.com/openstack/networking-odl
|
||||
|
||||
Networking-odl installation and configuration:
|
||||
|
||||
* https://docs.openstack.org/developer/networking-odl/installation.html
|
||||
|
||||
OpenvSwitch scenario with Openstack-Ansible:
|
||||
|
||||
* https://docs.openstack.org/developer/openstack-ansible-os_neutron/app-openvswitch.html
|
||||
|
||||
TLS Support on OpenDaylight OpenFlow plugin:
|
||||
|
||||
* https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:_TLS_Support
|
||||
|
||||
Secure Communication Between OpenFlow Switches and Controllers
|
||||
|
||||
* https://www.thinkmind.org/download.php?articleid=afin_2015_2_30_40047
|
||||
Loading…
Reference in New Issue
Block a user