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

Email: zhipengh@...

Office: Calit2 Building Room 2402