Re: [opendove-dev] [vtn-dev] ODL - Neutron API enhancement to include the southbound driver info


Anil Vishnoi
 

IMHO VTN,Dove,Affinity are the virtualization solution on top of ODL platform and openstack should be agnostic of these virtualization solution. ODL should be a southbound for openstack rather then specific solution running on top of it,  serving neutron services. 
In future if ODL hosts another virtualization solution then i believe rather then re-configuring neutron service for this new solution, switching at the controller level will be more convenient way to go about it. 

Just my 2 cents,

Thanks
Anil


On Wed, Dec 4, 2013 at 1:35 AM, Ed Warnicke (eaw) <eaw@...> wrote:

On Dec 2, 2013, at 9:55 PM, Hideyuki Tai <h-tai@...> wrote:

Hi Ed,
 
Madhu’s proposal focus on the co-existing problem between southbound drivers for Neutron Interface.
I explained about this problem in the following mail.
To solve this problem, I think Madhu’s proposal is good.
 
The co-existing problem between Affinity, VTN Manager, and simpleforwarding is a different problem.
In the Virtualization Edition, more than one application exist, and they try to control the same network resources simultaneously.
Because different applications have different policies on how to control network resources, it’s obvious that flow entries installed by different applications are inconsistent.
To solve this problem, we need other solution.

Agreed… I was just calling attention to the fact that while I think Madhu has made an elegant proposal for the 
Neutron side of this issue… we do need a better solution overall :)

Ed

 
Regards,
Hideyuki Tai
 
From: Ed Warnicke (eaw) [mailto:eaw@...] 
Sent: Tuesday, December 03, 2013 11:44 AM
To: Tai, Hideyuki
Cc: Madhu Venguopal; opendove-dev@...; vtn-dev@...; ovsdb-dev@...; Kyle Mestery (kmestery); <affinity-dev@...>; <discuss@...>
Subject: Re: [ovsdb-dev] [vtn-dev] ODL - Neutron API enhancement to include the southbound driver info
 
So I see the value of this... But what about Affinity?
 
Ed


On Dec 2, 2013, at 7:57 PM, "Hideyuki Tai" <h-tai@...> wrote:

Hi Madhu,
 
I completely agree with your opinion.
 
Regards,
Hideyuki Tai
 
From: vtn-dev-bounces@... [mailto:vtn-dev-bounces@...] On Behalf OfMadhu Venguopal

Sent: Tuesday, December 03, 2013 3:44 AM
To: opendove-dev@...; vtn-dev@...; ovsdb-dev@...; Kyle Mestery (kmestery)
Subject: [vtn-dev] ODL - Neutron API enhancement to include the southbound driver info
 
Hi Kyle, OpenDove, VTN & OVSDB devs,

Since we all have integrations completed with the Neutron nb-apis and these southbound drivers (ovsdb, open-dove, vtn) 
cannot co-exist in the same virtualization edition, I was thinking of extending the Neutron NB-API to include the information
on which Southbound driver to choose. By doing that, all of these bundles can co-exist in the same virtualization edition and
based on the Openstack/Neutron deployment, the customer can choose which ODL-southbound to use. This can be done along
with the existing configuration that is needed on the OpenStack to point to the ODL-Northbound API & the authentication details.
something like :

[[post-config|/etc/neutron/plugins/ml2/ml2_conf.ini]]
[ml2_odl]
url=http://192.168.56.1:8080/controller/nb/v2/neutron
username=admin
password=admin
southbound=[ovsdb | opendove | vtn]

We can ofcourse keep this configuration inside the OpenDaylight as well. But, having it done as part of Neutron provides a single
point of configuration and let the Neutron administrator decide on what is to be done, rather than depending on another administrator
who might handle the Opendaylight Controller.

Please share your opinion and I can get this thing done on the Opendaylight side.

Thanks,
Madhu
_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev


_______________________________________________
opendove-dev mailing list
opendove-dev@...
https://lists.opendaylight.org/mailman/listinfo/opendove-dev




--
Thanks
Anil

Join {z.archive.ovsdb-dev@lists.opendaylight.org to automatically receive all group messages.