Date   

Re: ovsdb topic branch for netty based json-rpc development

Brent Salisbury
 

+1. A topic branch is desperately needed. Apologies to Zhipeng and others in #opendaylight-ovsdb for dealing with forked repos in various locations. Replacing the library w/ Netty was too intrusive to try and do in the Main branch without completely breaking during the progress. Madhu, thanks for driving that bud.

Cheers,
-Brent


On Fri, Oct 11, 2013 at 5:18 PM, Evan Zeller <evanrzeller@...> wrote:
Sounds good to me


On Fri, Oct 11, 2013 at 5:03 PM, Madhu Venugopal <mavenugo@...> wrote:
Official ODL repo. 

-Madhu

On Oct 11, 2013, at 1:58 PM, Zhipeng Huang <zhipengh512@...> wrote:

hi Madhu,

Would you be update the github ovsdb_netty repo or there's gonna be a new branch out of official odl ovsdb gerrit git repo

Best

Zhipeng


On Fri, Oct 11, 2013 at 1:34 PM, Madhu Venguopal <mavenugo@...> wrote:

As discussed through various channels, I will go ahead and pull a topic branch under ovsdb for
the netty based json-rpc & marshal/de-marshal from/to java POJO objects using jackson.
I will also port most of the spread out code into this 1 location so that we can all start to contribute
in this branch without impacting the working master.

Please raise a flag if you have any concerns.

Thanks,
-Madhu

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



--
Zhipeng Huang
Master Of Science & Research Assistant
Mobile Ad-Hoc Network Lab
California Institute for Telecommunications and Information Technology
Department of Electric Engineering and Computer Science
Department of Networked Systems
University of California, Irvine
Office: Calit2 Building Room 2402


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




--
Brent Salisbury
Network Engineer
NEMOC/WAN
University of Kentucky
(859)257-2299
IM 323125686 (ICQ)


Re: ovsdb topic branch for netty based json-rpc development

Madhu Venugopal
 


Thanks guys. Will send out a note once I do most of the porting and some of testing done ;)

-Madhu

On 10/11/13 2:22 PM, Brent Salisbury wrote:

+1. A topic branch is desperately needed. Apologies to Zhipeng and others in #opendaylight-ovsdb for dealing with forked repos in various locations. Replacing the library w/ Netty was too intrusive to try and do in the Main branch without completely breaking during the progress. Madhu, thanks for driving that bud.

Cheers,
-Brent


On Fri, Oct 11, 2013 at 5:18 PM, Evan Zeller <evanrzeller@...> wrote:
Sounds good to me


On Fri, Oct 11, 2013 at 5:03 PM, Madhu Venugopal <mavenugo@...> wrote:
Official ODL repo. 

-Madhu

On Oct 11, 2013, at 1:58 PM, Zhipeng Huang <zhipengh512@...> wrote:

hi Madhu,

Would you be update the github ovsdb_netty repo or there's gonna be a new branch out of official odl ovsdb gerrit git repo

Best

Zhipeng


On Fri, Oct 11, 2013 at 1:34 PM, Madhu Venguopal <mavenugo@...> wrote:

As discussed through various channels, I will go ahead and pull a topic branch under ovsdb for
the netty based json-rpc & marshal/de-marshal from/to java POJO objects using jackson.
I will also port most of the spread out code into this 1 location so that we can all start to contribute
in this branch without impacting the working master.

Please raise a flag if you have any concerns.

Thanks,
-Madhu

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



--
Zhipeng Huang
Master Of Science & Research Assistant
Mobile Ad-Hoc Network Lab
California Institute for Telecommunications and Information Technology
Department of Electric Engineering and Computer Science
Department of Networked Systems
University of California, Irvine
Office: Calit2 Building Room 2402


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




--
Brent Salisbury
Network Engineer
NEMOC/WAN
University of Kentucky
(859)257-2299
IM 323125686 (ICQ)


Webex Recording of today's (10/22/13) meeting

Madhu Venugopal
 

Topics Discussed :

1. Migration plan to the newer Infrastructure
2. Birds eye view on Yang and how it make sense for ovsdb schema.
3. Risk evaluation on the final approach that will be taken for the Hydrogen release.
4. Summary on NB-API and integration concerns with OpenStack Neutron.

Action Items :

1. Madhu to commit all the local changes in the netty branch (Including Ashwin's awesome changes :-)).
2. Identify & update Trello with all the missing pieces after the commit ( Marshalling, Operations definition, Mutations, Schema definition completion on the POJOs, RPC method definition completion, etc...)
3. ovsdb-dev will pick up any open items and start working on it.
4. In Parallel, the master branch will still be active with the functionality portions tested and evaluated. As always Brent is leading that front.
5. Schedule a call with Kyle as soon as possible to clear up all the Neutron / ML2 API questions and integrate with OVSDB.

Thanks,
Madhu


Initial library commit in

Madhu Venugopal
 

Folks,

As you might have seen that I pushed the initial merged code from Brent, Evan & Aswin that covers
the Netty, JSON-RPC & Jackson based marshal/marshaling.

There is lot more work left still on the library side before getting the plugin stuffs to be fully integrated and operational. am working on it full time to get the library work done this week and hoping to give a talk on this on our weekly call next week.

I will also go ahead and add the missing pieces in Trello so that anyone interested and have time can jump in and start hashing it out on the topic/netty branch.

Thanks,
Madhu


Re: Webex Recording of today's (10/22/13) meeting

Madhu Venugopal
 


On Tue, Oct 22, 2013 at 2:17 PM, Madhu Venugopal <mavenugo@...> wrote:
Topics Discussed :

1. Migration plan to the newer Infrastructure
2. Birds eye view on Yang and how it make sense for ovsdb schema.
3. Risk evaluation on the final approach that will be taken for the Hydrogen release.
4. Summary on NB-API and integration concerns with OpenStack Neutron.

Action Items :

1. Madhu to commit all the local changes in the netty branch (Including Ashwin's awesome changes :-)).
2. Identify & update Trello with all the missing pieces after the commit ( Marshalling, Operations definition, Mutations, Schema definition completion on the POJOs, RPC method definition completion, etc...)
3. ovsdb-dev will pick up any open items and start working on it.
4. In Parallel, the master branch will still be active with the functionality portions tested and evaluated. As always Brent is leading that front.
5. Schedule a call with Kyle as soon as possible to clear up all the Neutron / ML2 API questions and integrate with OVSDB.

Thanks,
Madhu


Trello page for the Open Items

Madhu Venugopal
 

Folks,

As promised, Please use the following Trello page for task tracking
https://trello.com/b/SbPFDkvW/hydrogen-ovsdb

I added some initial stuffs to it & will continue to add all the missing items as I find it.

0. If not already, create a Trello account.
1. You can signup for any of the items in the above link (including the ones that some else has signed up).
2. Please feel free to add/delete/modify and move cards from TODO, DOING & DONE Lists
based on the progress.
3. Keep folks informed over email/IRC/phone/text :-) to make sure we dont end up with duplicate efforts.

Thanks,
Madhu


Re: Webex Recording of today's (10/22/13) meeting

Phil Robb
 


On Thu, Oct 24, 2013 at 10:39 AM, Madhu Venugopal <mavenugo@...> wrote:


On Tue, Oct 22, 2013 at 2:17 PM, Madhu Venugopal <mavenugo@...> wrote:
Topics Discussed :

1. Migration plan to the newer Infrastructure
2. Birds eye view on Yang and how it make sense for ovsdb schema.
3. Risk evaluation on the final approach that will be taken for the Hydrogen release.
4. Summary on NB-API and integration concerns with OpenStack Neutron.

Action Items :

1. Madhu to commit all the local changes in the netty branch (Including Ashwin's awesome changes :-)).
2. Identify & update Trello with all the missing pieces after the commit ( Marshalling, Operations definition, Mutations, Schema definition completion on the POJOs, RPC method definition completion, etc...)
3. ovsdb-dev will pick up any open items and start working on it.
4. In Parallel, the master branch will still be active with the functionality portions tested and evaluated. As always Brent is leading that front.
5. Schedule a call with Kyle as soon as possible to clear up all the Neutron / ML2 API questions and integrate with OVSDB.

Thanks,
Madhu


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




--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb


Re: Webex Recording of today's (10/22/13) meeting

Madhu Venugopal
 


Thanks Phil.

Will this link take care of all the subsequent weekly OVSDB meetings as well ?
Or will it be new link for every meeting ?

-Madhu

On 10/25/13 10:58 AM, Phil Robb wrote:



On Thu, Oct 24, 2013 at 10:39 AM, Madhu Venugopal <mavenugo@...> wrote:


On Tue, Oct 22, 2013 at 2:17 PM, Madhu Venugopal <mavenugo@...> wrote:
Topics Discussed :

1. Migration plan to the newer Infrastructure
2. Birds eye view on Yang and how it make sense for ovsdb schema.
3. Risk evaluation on the final approach that will be taken for the Hydrogen release.
4. Summary on NB-API and integration concerns with OpenStack Neutron.

Action Items :

1. Madhu to commit all the local changes in the netty branch (Including Ashwin's awesome changes :-)).
2. Identify & update Trello with all the missing pieces after the commit ( Marshalling, Operations definition, Mutations, Schema definition completion on the POJOs, RPC method definition completion, etc...)
3. ovsdb-dev will pick up any open items and start working on it.
4. In Parallel, the master branch will still be active with the functionality portions tested and evaluated. As always Brent is leading that front.
5. Schedule a call with Kyle as soon as possible to clear up all the Neutron / ML2 API questions and integrate with OVSDB.

Thanks,
Madhu


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




--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb


Re: Trello page for the Open Items

Brent Salisbury
 

This is great Madhu. Really appreciate it. I will get a link up from the Wiki to it.

Thanks,
-Brent


From: Madhu Venugopal <mavenugo@...>
Date: Thursday, October 24, 2013 3:53 PM
To: "ovsdb-dev@..." <ovsdb-dev@...>, brent <brent.salisbury@...>, Aswin Nair <aswinnair@...>, Zhipeng Huang <zhipengh512@...>, Evan Zeller <evanrzeller@...>
Subject: Trello page for the Open Items

Folks,

As promised, Please use the following Trello page for task tracking
https://trello.com/b/SbPFDkvW/hydrogen-ovsdb

I added some initial stuffs to it & will continue to add all the missing items as I find it.

0. If not already, create a Trello account.
1. You can signup for any of the items in the above link (including the ones that some else has signed up).
2. Please feel free to add/delete/modify and move cards from TODO, DOING & DONE Lists
based on the progress.
3. Keep folks informed over email/IRC/phone/text :-) to make sure we dont end up with duplicate efforts.

Thanks,
Madhu


Re: Webex Recording of today's (10/22/13) meeting

Phil Robb
 

Sadly, it's a new link for every meeting.  It sounds like you folks are moving to Google Hangouts anyway.  Sorry this didn't work out for you.

Phil.


On Fri, Oct 25, 2013 at 12:03 PM, Madhu Venguopal <mavenugo@...> wrote:

Thanks Phil.

Will this link take care of all the subsequent weekly OVSDB meetings as well ?
Or will it be new link for every meeting ?

-Madhu


On 10/25/13 10:58 AM, Phil Robb wrote:


On Thu, Oct 24, 2013 at 10:39 AM, Madhu Venugopal <mavenugo@...> wrote:


On Tue, Oct 22, 2013 at 2:17 PM, Madhu Venugopal <mavenugo@...> wrote:
Topics Discussed :

1. Migration plan to the newer Infrastructure
2. Birds eye view on Yang and how it make sense for ovsdb schema.
3. Risk evaluation on the final approach that will be taken for the Hydrogen release.
4. Summary on NB-API and integration concerns with OpenStack Neutron.

Action Items :

1. Madhu to commit all the local changes in the netty branch (Including Ashwin's awesome changes :-)).
2. Identify & update Trello with all the missing pieces after the commit ( Marshalling, Operations definition, Mutations, Schema definition completion on the POJOs, RPC method definition completion, etc...)
3. ovsdb-dev will pick up any open items and start working on it.
4. In Parallel, the master branch will still be active with the functionality portions tested and evaluated. As always Brent is leading that front.
5. Schedule a call with Kyle as soon as possible to clear up all the Neutron / ML2 API questions and integrate with OVSDB.

Thanks,
Madhu


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




--
Phil Robb
Director - Networking Solutions
The Linux Foundation
Skype: Phil.Robb




--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb


Re: Webex Recording of today's (10/22/13) meeting

Madhu Venugopal
 

No Problem Phil.

We found an awesome way to use Google Hangout for recording as well.
So we are good :)


On Sat, Oct 26, 2013 at 1:23 PM, Phil Robb <probb@...> wrote:
Sadly, it's a new link for every meeting.  It sounds like you folks are moving to Google Hangouts anyway.  Sorry this didn't work out for you.

Phil.


On Fri, Oct 25, 2013 at 12:03 PM, Madhu Venguopal <mavenugo@...> wrote:

Thanks Phil.

Will this link take care of all the subsequent weekly OVSDB meetings as well ?
Or will it be new link for every meeting ?

-Madhu


On 10/25/13 10:58 AM, Phil Robb wrote:


On Thu, Oct 24, 2013 at 10:39 AM, Madhu Venugopal <mavenugo@...> wrote:


On Tue, Oct 22, 2013 at 2:17 PM, Madhu Venugopal <mavenugo@...> wrote:
Topics Discussed :

1. Migration plan to the newer Infrastructure
2. Birds eye view on Yang and how it make sense for ovsdb schema.
3. Risk evaluation on the final approach that will be taken for the Hydrogen release.
4. Summary on NB-API and integration concerns with OpenStack Neutron.

Action Items :

1. Madhu to commit all the local changes in the netty branch (Including Ashwin's awesome changes :-)).
2. Identify & update Trello with all the missing pieces after the commit ( Marshalling, Operations definition, Mutations, Schema definition completion on the POJOs, RPC method definition completion, etc...)
3. ovsdb-dev will pick up any open items and start working on it.
4. In Parallel, the master branch will still be active with the functionality portions tested and evaluated. As always Brent is leading that front.
5. Schedule a call with Kyle as soon as possible to clear up all the Neutron / ML2 API questions and integrate with OVSDB.

Thanks,
Madhu


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




--
Phil Robb
Director - Networking Solutions
The Linux Foundation
Skype: Phil.Robb




--
Phil Robb
Director - Networking Solutions
The Linux Foundation
Skype: Phil.Robb


OpenDaylight OVSDB topic/netty branch status

Madhu Venugopal
 

Hi OVSDB-Devs,

Over the past few days, we were busy getting the topic/netty branch to shape after
migration to Netty and new Bi-directional JSON-RPC work
(Thanks to Brent, Aswin and Master Zeller's efforts).

I added a few more commits & brought all the branches together into the lib structure.
Also completed the integration with OVSDB Plugin's Connection & Inventory Service.

With most of the infra in place, I was able to get addBridge ConfigurationService working as well.

Please refer to all my recent commits to topic/netty branch :
https://git.opendaylight.org/gerrit/#/q/project:ovsdb,n,z

am also actively maintaining the Trello page :
https://trello.com/b/SbPFDkvW/hydrogen-ovsdb

For all of you, who signed up to handle some tasks, this is your time :-)
Pull the code and start hacking. If you guys need help getting starting with the new codebase,
I would be more than happy to call a google hangout session and bring you all upto speed.

Please add it to your circles and lets start sharing, polling, commenting and posting your cat pictures :-)

Thanks,
Madhu

PS : am still working on cleaning up the Library / Plugin code (its ugly looking at this point) :-)


Re: OpenDaylight OVSDB topic/netty branch status

Zhipeng Huang <zhipengh512@...>
 

thx madhu !


On Tue, Oct 29, 2013 at 4:29 PM, Madhu Venugopal <mavenugo@...> wrote:
Hi OVSDB-Devs,

Over the past few days, we were busy getting the topic/netty branch to shape after
migration to Netty and new Bi-directional JSON-RPC work
(Thanks to Brent, Aswin and Master Zeller's efforts).

I added a few more commits & brought all the branches together into the lib structure.
Also completed the integration with OVSDB Plugin's Connection & Inventory Service.

With most of the infra in place, I was able to get addBridge ConfigurationService working as well.

Please refer to all my recent commits to topic/netty branch :
https://git.opendaylight.org/gerrit/#/q/project:ovsdb,n,z

am also actively maintaining the Trello page :
https://trello.com/b/SbPFDkvW/hydrogen-ovsdb

For all of you, who signed up to handle some tasks, this is your time :-)
Pull the code and start hacking. If you guys need help getting starting with the new codebase,
I would be more than happy to call a google hangout session and bring you all upto speed.

Please add it to your circles and lets start sharing, polling, commenting and posting your cat pictures :-)

Thanks,
Madhu

PS : am still working on cleaning up the Library / Plugin code (its ugly looking at this point) :-)



--
Zhipeng Huang
Master Of Science & Research Assistant
Mobile Ad-Hoc Network Lab
California Institute for Telecommunications and Information Technology
Department of Electric Engineering and Computer Science
Department of Networked Systems
University of California, Irvine
Phone: 949-419-4241
Office: Calit2 Building Room 2402


Re: OpenDaylight OVSDB topic/netty branch status

Brent Salisbury
 

Thanks for marshaling all that together Madhu! I'm at ONUG until Thursday but have time tomorrow to get started.  
Thanks,
-Brent


From: Madhu Venugopal <mavenugo@...>
Date: Tuesday, October 29, 2013 7:29 PM
To: "ovsdb-dev@..." <ovsdb-dev@...>, brent <brent.salisbury@...>, Evan Zeller <evanrzeller@...>, Matt O <mierdin@...>, Zhipeng Huang <zhipengh512@...>, Aswin Nair <aswinnair@...>
Subject: OpenDaylight OVSDB topic/netty branch status

Hi OVSDB-Devs,

Over the past few days, we were busy getting the topic/netty branch to shape after
migration to Netty and new Bi-directional JSON-RPC work
(Thanks to Brent, Aswin and Master Zeller's efforts).

I added a few more commits & brought all the branches together into the lib structure.
Also completed the integration with OVSDB Plugin's Connection & Inventory Service.

With most of the infra in place, I was able to get addBridge ConfigurationService working as well.

Please refer to all my recent commits to topic/netty branch :
https://git.opendaylight.org/gerrit/#/q/project:ovsdb,n,z

am also actively maintaining the Trello page :
https://trello.com/b/SbPFDkvW/hydrogen-ovsdb

For all of you, who signed up to handle some tasks, this is your time :-)
Pull the code and start hacking. If you guys need help getting starting with the new codebase,
I would be more than happy to call a google hangout session and bring you all upto speed.

Please add it to your circles and lets start sharing, polling, commenting and posting your cat pictures :-)

Thanks,
Madhu

PS : am still working on cleaning up the Library / Plugin code (its ugly looking at this point) :-)


Re: OpenDaylight OVSDB topic/netty branch status

Hugo Trippaers <hugo@...>
 

Nice job!

Hope i can find the time to hack on it soon :D

Cheers,

Hugo

On 30 okt. 2013, at 07:26, Brent Salisbury <brent.salisbury@...> wrote:

Thanks for marshaling all that together Madhu! I'm at ONUG until Thursday but have time tomorrow to get started.
Thanks,
-Brent


From: Madhu Venugopal <mavenugo@...>
Date: Tuesday, October 29, 2013 7:29 PM
To: "ovsdb-dev@..." <ovsdb-dev@...>, brent <brent.salisbury@...>, Evan Zeller <evanrzeller@...>, Matt O <mierdin@...>, Zhipeng Huang <zhipengh512@...>, Aswin Nair <aswinnair@...>
Subject: OpenDaylight OVSDB topic/netty branch status

Hi OVSDB-Devs,

Over the past few days, we were busy getting the topic/netty branch to shape after
migration to Netty and new Bi-directional JSON-RPC work
(Thanks to Brent, Aswin and Master Zeller's efforts).

I added a few more commits & brought all the branches together into the lib structure.
Also completed the integration with OVSDB Plugin's Connection & Inventory Service.

With most of the infra in place, I was able to get addBridge ConfigurationService working as well.

Please refer to all my recent commits to topic/netty branch :
https://git.opendaylight.org/gerrit/#/q/project:ovsdb,n,z

am also actively maintaining the Trello page :
https://trello.com/b/SbPFDkvW/hydrogen-ovsdb

For all of you, who signed up to handle some tasks, this is your time :-)
Pull the code and start hacking. If you guys need help getting starting with the new codebase,
I would be more than happy to call a google hangout session and bring you all upto speed.

We also have a google plus page :-)
https://plus.google.com/u/0/110026533014641186687/posts

Please add it to your circles and lets start sharing, polling, commenting and posting your cat pictures :-)

Thanks,
Madhu

PS : am still working on cleaning up the Library / Plugin code (its ugly looking at this point) :-)
_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev


brainfart about parents and children

Hugo Trippaers <hugo@...>
 

Heya all,

Yesterday evening (CET ;-) ) i was having a nice chat with Madhu. We were talking about ways to make the OVSDB plugin as generic as possible to make sure we can talk to just about any ovsdb we encounter. Absolutely the way to go i think, but it raised a few question marks on how to deal with the idiosyncrasies of the various implementations that are going to pop-up. As we offer functions like create bridge domain and related functions we need to have some way to express how we would do that in a particular implementation. For example creating a bridge in openvswitch might be subtly different from creating it on vendor A switch or implementation X.

Hence the next question, if you look at ODL from a user perspective you would expect to be able to add a device like an openvswitch equipped hypervisor and i would expect ODL to know how to handle it. The ovsdb plugin is a good place, but there might be something needed on top of that, but in my opinion it should still be in ODL. Not being thoroughly knowledgable about ODL yet, i would expect something that would allow me to create a “parent” node of type openvswitch/vendor switch A/whatever with one “child” node of type OVS and zero or more child nodes of type OF (the bridges) or other types depending on the implementation. The OVS and other nodes would be “managed” by the parent node which know what to do when the owner of the node tells it to create a bridge domain.

Just idle rambling, but curious about this as it would impact how much intelligence the tools interfacing with ODL should need to have.

Cheers,

Hugo


Re: brainfart about parents and children

Madhu Venugopal
 

Hi Hugo,

Thanks for bringing this up and sharing your views on this.

I will share mine here and the possible ways to address it in ODL with its current architecture / design / principles.
We should certainly be able to come up with some clean design around this.

To begin with, as we all understand, the OVSDB mechanism is essentially a DB + JSON-RPC transport.
With OpenVSwitch defining its Schema for the tables that reside on the switches.
Any 3rd party / vendors can add extensions to the table or have entirely different set of schemas all together but just
retaining the OVSDB's transport mechanisms intact (as defined in http://tools.ietf.org/html/draft-pfaff-ovsdb-proto-02#section-4.1.6).

With that in mind, I started to reorganize our current OVSDB code into Library & Plugin.
As per my definition :
1. Library takes care of ONLY the generic OVSDB transport and DB mechanism
2. Plugin takes care of the provided services (such as Add bridge, add port, configure with tunnels, vlans, etc...).
(Will soon move them into 2 different OSGi bundles)

Hence to have keep with the separation of concerns principles, the Library development must NOT worry about any of the service requirements
and should just get the draft (http://tools.ietf.org/html/draft-pfaff-ovsdb-proto-02#section-4.1.6) implemented exactly as per the spec
(without having to worry anything about the hard-coded table structures : such as Bridge, Port, etc...). But, completely Schema driven as we
discussed yesterday. Hence when we talk about the OVSDB library development, there are no confusions on extensions or service provided.
It will just not worry about any of those & the only concern of this library is to handle maybe multiple versions of OVSDB transport draft (if any).

It is the plugin layer where the idiosyncrasies of various vendor implementations and the provided services come into play.
So, we have multiple ways to handle the extensions as well.
Take an example of a simple switch that uses the ovsdb mgmt mechanism. So, it is reasonable to provide services like the bridge creation,
port addition, etc... and have a plugin named OpenVSwitch plugin (which makes use of the OVSDB library) and can infact define this user facing
services (such as the existing ConfigurationService & InventoryService).
Any "extensions" provided by the vendor can be handled as the parent-child relationship as you mentioned (or) the vendor can come up with
his own plugin which is essentially a "fragment" bundle which attaches to the OpenVSwitch plugin (or) the vendor can come up with his own
plugin all together which doesnt share anything with the OpenVSwitch plugin & can expose its own services in its own way.

With any of the above Plugin choices, all of them will make use of the exact same OVSDB library that is the heart of the communication between
the Controller and the ovsdb-server agent.

So, as a first step, we can try and get this generic Library to be implemented, while we can work on the plugin architecture for such an extension.
Just my 2c.

Thanks,
Madhu

On 11/2/13, 5:51 AM, Hugo Trippaers wrote:
Heya all,

Yesterday evening (CET ;-) ) i was having a nice chat with Madhu. We were talking about ways to make the OVSDB plugin as generic as possible to make sure we can talk to just about any ovsdb we encounter. Absolutely the way to go i think, but it raised a few question marks on how to deal with the idiosyncrasies of the various implementations that are going to pop-up. As we offer functions like create bridge domain and related functions we need to have some way to express how we would do that in a particular implementation. For example creating a bridge in openvswitch might be subtly different from creating it on vendor A switch or implementation X.

Hence the next question, if you look at ODL from a user perspective you would expect to be able to add a device like an openvswitch equipped hypervisor and i would expect ODL to know how to handle it. The ovsdb plugin is a good place, but there might be something needed on top of that, but in my opinion it should still be in ODL. Not being thoroughly knowledgable about ODL yet, i would expect something that would allow me to create a “parent” node of type openvswitch/vendor switch A/whatever with one “child” node of type OVS and zero or more child nodes of type OF (the bridges) or other types depending on the implementation. The OVS and other nodes would be “managed” by the parent node which know what to do when the owner of the node tells it to create a bridge domain.

Just idle rambling, but curious about this as it would impact how much intelligence the tools interfacing with ODL should need to have.

Cheers,

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


Re: brainfart about parents and children

Zhipeng Huang <zhipengh512@...>
 

I think odl-openflow also has this kind of lib/plugin devision. Is is correct to say maybe the lib part should fall in the sal layer, so there is a general modeling for the SB component while plugin provide the actual ability ?

Best

Zhipeng


On Sat, Nov 2, 2013 at 9:01 AM, Madhu Venguopal <mavenugo@...> wrote:
Hi Hugo,

Thanks for bringing this up and sharing your views on this.

I will share mine here and the possible ways to address it in ODL with its current architecture / design / principles.
We should certainly be able to come up with some clean design around this.

To begin with, as we all understand, the OVSDB mechanism is essentially a DB + JSON-RPC transport.
With OpenVSwitch defining its Schema for the tables that reside on the switches.
Any 3rd party / vendors can add extensions to the table or have entirely different set of schemas all together but just
retaining the OVSDB's transport mechanisms intact (as defined in http://tools.ietf.org/html/draft-pfaff-ovsdb-proto-02#section-4.1.6).

With that in mind, I started to reorganize our current OVSDB code into Library & Plugin.
As per my definition :
1. Library takes care of ONLY the generic OVSDB transport and DB mechanism
2. Plugin takes care of the provided services (such as Add bridge, add port, configure with tunnels, vlans, etc...).
(Will soon move them into 2 different OSGi bundles)

Hence to have keep with the separation of concerns principles, the Library development must NOT worry about any of the service requirements
and should just get the draft (http://tools.ietf.org/html/draft-pfaff-ovsdb-proto-02#section-4.1.6) implemented exactly as per the spec
(without having to worry anything about the hard-coded table structures : such as Bridge, Port, etc...). But, completely Schema driven as we
discussed yesterday. Hence when we talk about the OVSDB library development, there are no confusions on extensions or service provided.
It will just not worry about any of those & the only concern of this library is to handle maybe multiple versions of OVSDB transport draft (if any).

It is the plugin layer where the idiosyncrasies of various vendor implementations and the provided services come into play.
So, we have multiple ways to handle the extensions as well.
Take an example of a simple switch that uses the ovsdb mgmt mechanism. So, it is reasonable to provide services like the bridge creation,
port addition, etc... and have a plugin named OpenVSwitch plugin (which makes use of the OVSDB library) and can infact define this user facing
services (such as the existing ConfigurationService & InventoryService).
Any "extensions" provided by the vendor can be handled as the parent-child relationship as you mentioned (or) the vendor can come up with
his own plugin which is essentially a "fragment" bundle which attaches to the OpenVSwitch plugin (or) the vendor can come up with his own
plugin all together which doesnt share anything with the OpenVSwitch plugin & can expose its own services in its own way.

With any of the above Plugin choices, all of them will make use of the exact same OVSDB library that is the heart of the communication between
the Controller and the ovsdb-server agent.

So, as a first step, we can try and get this generic Library to be implemented, while we can work on the plugin architecture for such an extension.
Just my 2c.

Thanks,
Madhu


On 11/2/13, 5:51 AM, Hugo Trippaers wrote:
Heya all,

Yesterday evening (CET ;-) ) i was having a nice chat with Madhu. We were talking about ways to make the OVSDB plugin as generic as possible to make sure we can talk to just about any ovsdb we encounter. Absolutely the way to go i think, but it raised a few question marks on how to deal with the idiosyncrasies of the various implementations that are going to pop-up. As we offer functions like create bridge domain and related functions we need to have some way to express how we would do that in a particular implementation. For example creating a bridge in openvswitch might be subtly different from creating it on vendor A switch or implementation X.

Hence the next question, if you look at ODL from a user perspective you would expect to be able to add a device like an openvswitch equipped hypervisor and i would expect ODL to know how to handle it. The ovsdb plugin is a good place, but there might be something needed on top of that, but in my opinion it should still be in ODL. Not being thoroughly knowledgable about ODL yet, i would expect something that would allow me to create a “parent” node of type openvswitch/vendor switch A/whatever with one “child” node of type OVS and zero or more child nodes of type OF (the bridges) or other types depending on the implementation. The OVS and other nodes would be “managed” by the parent node which know what to do when the owner of the node tells it to create a bridge domain.

Just idle rambling, but curious about this as it would impact how much intelligence the tools interfacing with ODL should need to have.

Cheers,

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

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



--
Zhipeng Huang
Master Of Science & Research Assistant
Mobile Ad-Hoc Network Lab
California Institute for Telecommunications and Information Technology
Department of Electric Engineering and Computer Science
Department of Networked Systems
University of California, Irvine
Phone: 949-419-4241
Office: Calit2 Building Room 2402


Re: brainfart about parents and children

Madhu Venugopal
 


Yes & Yes.

The current implementation is not based on a modeling language (such as JsonSchema / Yang).
But, we have JSON schema based modeling as well - which is the default for OVSDB.
(& as you know :) , we also have a Trello task tracking the Yang related modeling as well).

Thanks,
Madhu

On 11/2/13, 12:11 PM, Zhipeng Huang wrote:

I think odl-openflow also has this kind of lib/plugin devision. Is is correct to say maybe the lib part should fall in the sal layer, so there is a general modeling for the SB component while plugin provide the actual ability ?

Best

Zhipeng


On Sat, Nov 2, 2013 at 9:01 AM, Madhu Venguopal <mavenugo@...> wrote:
Hi Hugo,

Thanks for bringing this up and sharing your views on this.

I will share mine here and the possible ways to address it in ODL with its current architecture / design / principles.
We should certainly be able to come up with some clean design around this.

To begin with, as we all understand, the OVSDB mechanism is essentially a DB + JSON-RPC transport.
With OpenVSwitch defining its Schema for the tables that reside on the switches.
Any 3rd party / vendors can add extensions to the table or have entirely different set of schemas all together but just
retaining the OVSDB's transport mechanisms intact (as defined in http://tools.ietf.org/html/draft-pfaff-ovsdb-proto-02#section-4.1.6).

With that in mind, I started to reorganize our current OVSDB code into Library & Plugin.
As per my definition :
1. Library takes care of ONLY the generic OVSDB transport and DB mechanism
2. Plugin takes care of the provided services (such as Add bridge, add port, configure with tunnels, vlans, etc...).
(Will soon move them into 2 different OSGi bundles)

Hence to have keep with the separation of concerns principles, the Library development must NOT worry about any of the service requirements
and should just get the draft (http://tools.ietf.org/html/draft-pfaff-ovsdb-proto-02#section-4.1.6) implemented exactly as per the spec
(without having to worry anything about the hard-coded table structures : such as Bridge, Port, etc...). But, completely Schema driven as we
discussed yesterday. Hence when we talk about the OVSDB library development, there are no confusions on extensions or service provided.
It will just not worry about any of those & the only concern of this library is to handle maybe multiple versions of OVSDB transport draft (if any).

It is the plugin layer where the idiosyncrasies of various vendor implementations and the provided services come into play.
So, we have multiple ways to handle the extensions as well.
Take an example of a simple switch that uses the ovsdb mgmt mechanism. So, it is reasonable to provide services like the bridge creation,
port addition, etc... and have a plugin named OpenVSwitch plugin (which makes use of the OVSDB library) and can infact define this user facing
services (such as the existing ConfigurationService & InventoryService).
Any "extensions" provided by the vendor can be handled as the parent-child relationship as you mentioned (or) the vendor can come up with
his own plugin which is essentially a "fragment" bundle which attaches to the OpenVSwitch plugin (or) the vendor can come up with his own
plugin all together which doesnt share anything with the OpenVSwitch plugin & can expose its own services in its own way.

With any of the above Plugin choices, all of them will make use of the exact same OVSDB library that is the heart of the communication between
the Controller and the ovsdb-server agent.

So, as a first step, we can try and get this generic Library to be implemented, while we can work on the plugin architecture for such an extension.
Just my 2c.

Thanks,
Madhu


On 11/2/13, 5:51 AM, Hugo Trippaers wrote:
Heya all,

Yesterday evening (CET ;-) ) i was having a nice chat with Madhu. We were talking about ways to make the OVSDB plugin as generic as possible to make sure we can talk to just about any ovsdb we encounter. Absolutely the way to go i think, but it raised a few question marks on how to deal with the idiosyncrasies of the various implementations that are going to pop-up. As we offer functions like create bridge domain and related functions we need to have some way to express how we would do that in a particular implementation. For example creating a bridge in openvswitch might be subtly different from creating it on vendor A switch or implementation X.

Hence the next question, if you look at ODL from a user perspective you would expect to be able to add a device like an openvswitch equipped hypervisor and i would expect ODL to know how to handle it. The ovsdb plugin is a good place, but there might be something needed on top of that, but in my opinion it should still be in ODL. Not being thoroughly knowledgable about ODL yet, i would expect something that would allow me to create a “parent” node of type openvswitch/vendor switch A/whatever with one “child” node of type OVS and zero or more child nodes of type OF (the bridges) or other types depending on the implementation. The OVS and other nodes would be “managed” by the parent node which know what to do when the owner of the node tells it to create a bridge domain.

Just idle rambling, but curious about this as it would impact how much intelligence the tools interfacing with ODL should need to have.

Cheers,

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

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



--
Zhipeng Huang
Master Of Science & Research Assistant
Mobile Ad-Hoc Network Lab
California Institute for Telecommunications and Information Technology
Department of Electric Engineering and Computer Science
Department of Networked Systems
University of California, Irvine
Phone: 949-419-4241
Office: Calit2 Building Room 2402


Sample Bundles in the Virtualization Edition

Hideyuki Tai <h-tai@...>
 

Hi Virtualization Edition people,

Do any projects in the Virtualization Edition need sample bundles?
- org.opendaylight.controller.samples.loadbalancer
- org.opendaylight.controller.samples.sample-toaster
- org.opendaylight.controller.samples.simpleforwarding

Is it ok to remove all sample bundles from the Virtualization Edition?

These bundles are just *sample* bundles,
and already included in the Base Edition.

Furthermore, VTN Manager does not correctly work,
if samples.loadbalancer or samples.simpleforwarding is running.
These bundles set flow entries to switches,
so it might break flow entries set by VTN Manager.

Therefore, if all bundles delivered by projects in the Virtualization Edition
does not need these bundles,
I would like to remove sample bundles from the Virtualization Edition.

Thanks,
Hideyuki Tai

41 - 60 of 4855