From Hugo Trippaers <hugo@...>:

Hugo Trippaers has posted comments on this change.

Change subject: Implemented the deleteBridgeDomain method in ConfigurationService
......................................................................


Patch Set 1: Code-Review+1

(2 comments)

You beat me to it, was just working on the same thing ;-)

....................................................
File ovsdb/src/main/java/org/opendaylight/ovsdb/plugin/ConfigurationService.java
Line 606: if (tr.get(i).getError() != null && tr.get(i).getError().trim().length() > 0) {
With openvswitch it is possible that a transaction returns an array with null elements. As there is only one transaction here it is not a big risk. But for safety we should check if tr.get(i) != null


Line 877: status = this.deleteBridgeDomain(Node.fromString(nodeName), bridgeName);
Node.fromString can return null. deleteBridgeDomain doesn't check this resulting in an NPE. Should we check for this even though this is a debug function?

From Hugo Trippaers <hugo@...>:

Hugo Trippaers has posted comments on this change.

Change subject: Implemented the deleteBridgeDomain method in ConfigurationService
......................................................................


Patch Set 1: Code-Review+1

(2 comments)

You beat me to it, was just working on the same thing ;-)

....................................................
File ovsdb/src/main/java/org/opendaylight/ovsdb/plugin/ConfigurationService.java
Line 606: if (tr.get(i).getError() != null && tr.get(i).getError().trim().length() > 0) {
With openvswitch it is possible that a transaction returns an array with null elements. As there is only one transaction here it is not a big risk. But for safety we should check if tr.get(i) != null


Line 877: status = this.deleteBridgeDomain(Node.fromString(nodeName), bridgeName);
Node.fromString can return null. deleteBridgeDomain doesn't check this resulting in an NPE. Should we check for this even though this is a debug function?

hi madhu, 

I switched to master and lib/plugin division is gone, is this right ?

On Wed, Nov 6, 2013 at 7:08 PM, Madhu Venguopal <mavenugo@...> wrote:

Collapse is done. Please port any pending changes in the netty branch to the Master and continue hacking.
We ported most of the Configuration Services to the new infra. Please submit a patch and fix any of missing service.

-Madhu

On 11/6/13, 12:21 PM, Brent Salisbury wrote:

My only concern is that it may be too awesome :) Thanks for everyones work
on it and the opportunity to participate. I think we should be close to 10
different organizations both vendor and non-vendor contributing. Quite a
commentary on the ODL project and the OVSDB project teamwork. Madhu,
brilliant job marshaling us through the process.

Respect,
-Brent





On 11/6/13 2:34 PM, "Madhu Venguopal" <mavenugo@...> wrote:

Hi Devs,

We got most of the fixes that we originally targeted for in the netty
branch and planning to collapse it back to master today.
Please let us know if you have any inputs/concerns.

-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

Phone: 949-419-4241

Email: zhipengh@...

Office: Calit2 Building Room 2402

My only concern is that it may be too awesome :) Thanks for everyones work
on it and the opportunity to participate. I think we should be close to 10
different organizations both vendor and non-vendor contributing. Quite a
commentary on the ODL project and the OVSDB project teamwork. Madhu,
brilliant job marshaling us through the process.

Respect,
-Brent





On 11/6/13 2:34 PM, "Madhu Venguopal" <mavenugo@...> wrote:

Hi Devs,

We got most of the fixes that we originally targeted for in the netty
branch and planning to collapse it back to master today.
Please let us know if you have any inputs/concerns.

-Madhu

Hi Alissa, Prasanth,

As we all agree, REST-API definitions are more of recommendations and conventions that are widely used.
And the definitions for PUT, POST are a bit vague. Having said that, it is better to follow a convention that
is widely accepted norm. It will be a disaster if each of the projects decide to go with its own convention.
Rather there MUST be a standardized approach.

With REST-CONF development also underway, we need to find that consensus and fast.

IMHO, The API freeze deadline that was set in the past didnt workout as expected.
Since we are NOT discussing about functionality changes and merely the best practice / convention on defining
the REST-API, I would recommend to take inputs from the community and other experts who had dealt with REST-API
definitions in the past.

Again, it is highly recommended to follow a well-known convention (AWS, OpenStack, etc...) and stick to it.

Since the TWS call for this week was cancelled, either we can take it up in the next week call
(or) I can call one this week and hope most of the experts and stake-holders can make it.

So, far we have just heard from 4-5 of us on this topic (and I hope the inclusion of discuss alias and subject change will help).

Thanks,
Madhu

On 11/5/13, 12:37 AM, Alissa Bonas wrote:

----- Original Message -----

From: "Prasanth Pallamreddy (ppallamr)" <ppallamr@...>
To: "Alissa Bonas" <abonas@...>
Cc: "Madhu Venugopal" <mavenugo@...>, "Ryan Moats" <rmoats@...>, "Giovanni Meo (gmeo)" <gmeo@...>,
"Anees A Shaikh" <aashaikh@...>, "controller-dev" <controller-dev@...>, "Nikhileshkumar
Ikhar" <nikhil.ikhar@...>
Sent: Tuesday, November 5, 2013 5:48:30 AM
Subject: Re: [controller-dev] Unable to add user with command line

See inline ... [PP]


On 11/4/13 12:21 PM, "Alissa Bonas" <abonas@...> wrote:

Prasanth,

I am still failing to understand why PUT is better for creating new
entities.]
Based on the amazon web practices that you enclosed, it states that most
of the cases use POST when creating new entities.

And looking at the http spec, it also states that POST is used to create
new entities as well:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Please also see this article on REST api design:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Using PUT for creating new entities does not provide a clear separation
for user which will have to use it for both creation and update. It is
very misleading for clients to use same api for 2 different purposes.

[PP] As I said earlier, the issue is grasping whether an update operation
is idempotent or not. Not all update operations are idempotent in which
case you'd have an overloaded POST to handle both create and update
operations. So, the same question and confusion remains. Again, I am not
talking just about the user manager API, but rather all the APIs that have
been exposed in ODL. Also, not all APIs adhere to the 'PUT for create'
recommendation. If you look at FlowProgrammer NB, you'd see that the PUT
method has been overloaded to handle both creates and updates since the
POST has been reserved for some other operation.

Moreover, it is not recommended for clients to define their own urls on
server, or in other words to use non existing urls as in case when using
PUT for creation. Why the clients should use non existing urls or have
assumptions about it? All client wants is to add a new entity to an
existing collection (user/host/switch/etc.), and he should not interfere
with server's work to do so, he needs to supply the details of what
should be created and that's it. And consider this case - the resource
identifier may be (and in most cases it is) an id that server generates,
not a name that client sends. How in this case the client will create the
url of something that doesn't exist yet and is up to server to generate?

[PP] The current APIs that we expose, in almost all the cases, the
resource path is known. The server can reject the request if the requested
resource path doesn't comply. In some of the APIs there is redundant
resource information (in the path and the request payload) and the server
rejects it if there is a mismatch. Also, this isn't a hard rule. So, for
cases where the path is server generated, POST can be used. I wouldn't
admit that the APIs are perfect. Since we are in API freeze currently, the
issues can be addressed in v3.

What is the timeline for v3?

Hi Devs,

We got most of the fixes that we originally targeted for in the netty
branch and planning to collapse it back to master today.
Please let us know if you have any inputs/concerns.

-Madhu

-----Original Message-----
From: Ed Warnicke (eaw) [mailto:eaw@...]
Sent: Wednesday, November 06, 2013 12:19 AM
To: Tai, Hideyuki
Cc: <affinity-dev@...>; opendove-dev@...; ovsdb-dev@...;
<defense4all-dev@...>; vtn-dev@...
Subject: Re: [affinity-dev] Sample Bundles in the Virtualization Edition

Hideyuki,
My one concern on removing simple forwarding is to make sure that we have
a virtualization edition that, when someone runs run.sh, *does* something useful
(ie, pinball works) without requiring much if any configuration... thoughts?

Ed
On Nov 5, 2013, at 3:12 AM, Hideyuki Tai <h-tai@...> wrote:

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

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

-----Original Message-----
From: Ed Warnicke (eaw) [mailto:eaw@...]
Sent: Wednesday, November 06, 2013 12:19 AM
To: Tai, Hideyuki
Cc: <affinity-dev@...>; opendove-dev@...; ovsdb-dev@...;
<defense4all-dev@...>; vtn-dev@...
Subject: Re: [affinity-dev] Sample Bundles in the Virtualization Edition

Hideyuki,
My one concern on removing simple forwarding is to make sure that we have
a virtualization edition that, when someone runs run.sh, *does* something useful
(ie, pinball works) without requiring much if any configuration… thoughts?

Ed
On Nov 5, 2013, at 3:12 AM, Hideyuki Tai <h-tai@...> wrote:

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

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

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

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

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

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