Isolate DragonFlow from OpenStack to create a stand-alone distributed SDN-controller

Asked by Benjamin Vollmer

Hi all,
I am working on a solution for a distributed SDN-controller with a pluggable database.
Your DragonFlow solution already offers this feature.

Therefore I want to Isolate DragonFlow from OpenStack and create a standalone distributed SDN-controller from it.

Is this possible or is OpenStack an inseparable part of DragonFlow?

Best regards,
Benjamin Vollmer

Student of computer science
at University of Tuebingen

<email address hidden>

Question information

Language:
English Edit question
Status:
Solved
For:
DragonFlow Edit question
Assignee:
No assignee Edit question
Solved by:
Benjamin Vollmer
Solved:
Last query:
Last reply:
Revision history for this message
Omer Anson (omer-anson) said :
#1

Hi, Benjamin.

Currently Dragonflow uses openstack for API and libraries. Mostly, the libraries are lightweight and I believe can also be used in a standalone deployment (I think a pip install will take care of this).

The API is a bit more complex, but Dragonflow models are well defined since the latest release, which means writing a replacement API should be doable. It was on our roadmap, albeit with low priority.

We'd be happy to help make this happen.

Thanks,
Omer.

Revision history for this message
Benjamin Vollmer (benny93) said :
#2

Hi, Omer.
Thank you for your response.

I would like to write such a replacement API.

As I understand it, the OpenStack API in the project consists of:
- neutron_lib
- neutron
- networking_sfc

Are those all modules that I need to replace?

Is there some additional source code documentation (including overviews about the dependencies of the classes)?

May I contact you directly for further questions (via your launchpad account email)?

Best regards,
Benjamin Vollmer

Revision history for this message
Omer Anson (omer-anson) said :
#3

Hi, Benjamin.

Yes, these are the libraries you will need to remove. networking_sfc is easily swapped out, but neutron and neutron_lib will be more difficult, as we rely on them as libraries. I'd suggest that for a first try, to leave them as libraries (if possible), but not run the services they provide.

There are a few oslo packages, and ovsdbapp, which are openstack projects. I think that's all. But these are library projects, and not trivial to replace. Is there a reason you have to remove them?

Sadly no. Our documentation is somewhat lacking. One of our team-mates wrote a reference guide for himself, I can ask if he can share it (It is very incomplete). But it would be a good idea for us to write something like that.

You are welcome to contact me. My launchpad profile is up-to-date.

Thanks,
Omer.

Revision history for this message
Benjamin Vollmer (benny93) said :
#4

Hi, Omar.
Thank you again for your reply!

I think I'll keep the libraries for the beginning. The closer I stay with the original project, the more compatible stay the two versions with another. That way it's easier to integrate future developments of DragonFlow into the isolated version.

I think the reference-guide would be of great help for me. I'd appreciate it if you could send it to me. I'll close this question and write you directly in the future.

Best regards,
Benjamin

Revision history for this message
Khayam Gondal (khayamgondal) said :
#5

Benjamin, I am interested too. Have you started any work on this so far ?

Revision history for this message
Benjamin Vollmer (benny93) said :
#6

Hi Khayam Gondal,
I forked the DF project at:
https://github.com/Benny93/dragonflow

In the dragonflow/etc folder you can find my dragonflow.ini and neutron.conf.
I also changed the Vagrant boxes (controller1) to represent a "Switch -- Router -- Controller" Topology and updated the Vagrantfile to use Ubuntu 16.04 for OVS 2.5 support.

For the Standalone I wrote some concept classes in dragonflow/tests/df_standalone.
But be aware that this is just prototyping and does not represent anything useful in a real world system.

The latest concept its the l2_app_concept2.py.
Basically it is a modified version of Ryu's SimpleSwitch13.py that uses the DF DB-Driver to store data into the Database and gives the user the option to also replicate the database state in the cache of the controller (for faster replies).

The concept here is to allow the user the selection of cache usage per app (and therefore the consistency property of the data the app works with)

Redis-DB I use: https://github.com/Grokzen/docker-redis-cluster

My current workflow:
(Everything runs only on controller1 for now)
- Startup controller1: vagrant up controller1
- Install requirements.txt and test-requirements.txt with pip.
- Startup a Redis cluster (inside docker-redis-cluster folder): make run
- Startup the switch (inside the mininet folder, mininet needs to be run as root): ./python-sudo testbed0/scratchnet_...ipv4.py
- Startup the controller (starting l2_app_concept2.py): python2 dragonflow/tests/df_standalone/test_run_standalone.py

Feel free to contact me directly for any further questions.

Best regards,
Benjamin