Date   

Re: [ovsdb-gerrit] Change in ovsdb[master]: Implemented the deleteBridgeDomain method in ConfigurationSe...

Luis Gomez <luis.gomez@...>
 

Good idea, I just setup Trello for Integration group, we do not want to step into same issue :)

-----Original Message-----
From: ovsdb-dev-bounces@... [mailto:ovsdb-dev-bounces@...] On Behalf Of Madhu Venguopal
Sent: Friday, November 08, 2013 2:58 AM
To: hugo@...; Brent Salisbury
Cc: ovsdb-dev@...
Subject: Re: [ovsdb-dev] [ovsdb-gerrit] Change in ovsdb[master]: Implemented the deleteBridgeDomain method in ConfigurationSe...


It would help if we use Trello effectively to avoid effort duplication :)

-Madhu

On 11/8/13, 1:26 AM, Gerrit Code Review wrote:
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?

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


Re: [ovsdb-gerrit] Change in ovsdb[master]: Implemented the deleteBridgeDomain method in ConfigurationSe...

Madhu Venugopal
 

It would help if we use Trello effectively to avoid effort duplication :)

-Madhu

On 11/8/13, 1:26 AM, Gerrit Code Review wrote:
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?


Re: [vtn-dev] Fwd: [affinity-dev] Sample Bundles in the Virtualization Edition

Colin Dixon <ckd@...>
 

I agree 100%.

--Colin

Luis Gomez <luis.gomez@...> wrote on 11/07/2013 02:16:07 PM:
> From: Luis Gomez <luis.gomez@...>

> To: Colin Dixon/Austin/IBM@IBMUS, "<affinity-
> dev@...>" <affinity-dev@...>,
> "<opendove-dev@...>" <opendove-
> dev@...>, "<ovsdb-dev@...>"
> <ovsdb-dev@...>, "<defense4all-
> dev@...>" <defense4all-
> dev@...>, "<vtn-dev@...>"
> <vtn-dev@...>, "dev (controller-
> dev@...)" <controller-dev@...>

> Date: 11/07/2013 02:28 PM
> Subject: RE: [vtn-dev] Fwd: [affinity-dev] Sample Bundles in the
> Virtualization Edition

>
> Hi Colin,

>  
> I support the idea of having apps and features doing something
> useful with very few (b) or no configuration (a). Only concern is
> for those that do not require configuration (a), at least make sure
> they have very low or none impact in the controller behavior or
> switches configuration. A good example is Topology Manager that
> without any configuration reads information from the switches and
> creates a topology with no impact in controller/switches. On the
> other side we have Simple Forwarding app that writes flows in the
> switches whenever the controller discovers a host, I think this is
> quite an impact for an app that runs out of the box. With this I do
> not mean to remove this feature or other features like this but move
> them to (b) -> enable them with simple configuration, what you are
> actually proposing.

>  
> On the other hand, I take the chance to encourage the projects to
> come up with a simple (first contact) demo case for their
> contributions and publish it in the wiki, same thing OVSDB folks
> have done today at TSC call:

>  
> https://wiki.opendaylight.org/view/OVSDB_Integration:Mininet_OVSDB_Tutorial
> Thanks/Luis
>  
>  
>  
> From: vtn-dev-bounces@... [mailto:vtn-dev-
> bounces@...] On Behalf Of Colin Dixon
> Sent: Wednesday, November 06, 2013 2:45 PM
> To: <affinity-dev@...>; <opendove-
> dev@...>; <ovsdb-dev@...>;
> <defense4all-dev@...>; <vtn-dev@...>
> Subject: Re: [vtn-dev] Fwd: [affinity-dev] Sample Bundles in the
> Virtualization Edition

>  
> For what it's worth, I'm in the process of removing the requirements
> to configure SimpleFowarding so that it acts as a normal L2 switch
> across all the ports in the system when there's no configuration.
>
> I'm probably the primary reason that Ed says it should do
> *something* when it comes up because I've been hammering like crazy
> on that point for the base edition. I'm not sure it's as critical
> here that it work immediately out of the box, but making sure that
> either (a) it does something without configuration when it comes up
> or (b) we do really good job of explaining what configuration needs
> to be done and give some useful error if we do nothing.
>
> Does that seem reasonable to people?
>
> In the long run, maybe we should talk about having a
> NotSoSimpleForwarding bundle that is designed to take in affinity
> information, virtual networks, etc. and implement them properly
> rather than having each different solution manage the rules on their
> own. This would help separate the policy from the actual routes and
> allow for faster innovation in both.
>
> --Colin
>
> > From: Hideyuki Tai <h-tai@...>
> > Date: November 5, 2013 at 8:40:39 PM CST
> > To: "Ed Warnicke (eaw)" <eaw@...>
> > Cc: "<affinity-dev@...>" <affinity-
> > dev@...>, "opendove-dev@..." <
> > opendove-dev@...>, "ovsdb-dev@..." <
> > ovsdb-dev@...>, "<defense4all-dev@...
> > >" <defense4all-dev@...>, "vtn-dev@...
> > " <vtn-dev@...>
> > Subject: RE: [affinity-dev] Sample Bundles in the Virtualization Edition
>
> > Hi Ed,
> >
> > When someone runs run.sh and send some configuration to Affinity,
> > OpenDOVE, or VTN,
> > the Virtualization Edition does something useful.
> > It requires some configuration, but it does something great related
> > to virtualization.
> >
> > I think it's the same with simpleforwarding bundle to require configuration.
> > Simpleforwarding bundle requires subnet gateway configuration to
> > forward packets.
> > I mean that even the Virtualization Edition include simpleforwarding,
> > we need some configuration anyway.
> >
> > My one concern on simpleforwarding bundle is that simpleforwarding
> > sets flow entries automatically
> > after detecting host information.
> > It means that simpleforwarding ignore virtual network configuration
> > on Affinity and VTN,
> > and may install flow entries which interfere with Affinity and VTN.
> >
> > Therefore, I would like to remove simpleforwarding bundle from the
> > Virtualization Edition.
> >
> > Furthermore, I think simpleforwarding bundle doesn't do virtualization jobs,
> > but just simulates a traditional IP network.
> > So it is a little weird to me that the Virtualization Edition
> > include simpleforwarding bundle.
> >
> > To be honest, It's not clear to me that other project in the
> > Virtualization Edtion needs simpleforwarding bundle,
> > or simpleforwarding bundle interfere with other bundles too.
> > So I would like to hear from other project people.
> >
> > Regards,
> > Hideyuki Tai
>

> > -----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


Re: [vtn-dev] Fwd: [affinity-dev] Sample Bundles in the Virtualization Edition

Luis Gomez <luis.gomez@...>
 

Hi Colin,

 

I support the idea of having apps and features doing something useful with very few (b) or no configuration (a). Only concern is for those that do not require configuration (a), at least make sure they have very low or none impact in the controller behavior or switches configuration. A good example is Topology Manager that without any configuration reads information from the switches and creates a topology with no impact in controller/switches. On the other side we have Simple Forwarding app that writes flows in the switches whenever the controller discovers a host, I think this is quite an impact for an app that runs out of the box. With this I do not mean to remove this feature or other features like this but move them to (b) -> enable them with simple configuration, what you are actually proposing.

 

On the other hand, I take the chance to encourage the projects to come up with a simple (first contact) demo case for their contributions and publish it in the wiki, same thing OVSDB folks have done today at TSC call:

 

https://wiki.opendaylight.org/view/OVSDB_Integration:Mininet_OVSDB_Tutorial

Thanks/Luis

 

 

 

From: vtn-dev-bounces@... [mailto:vtn-dev-bounces@...] On Behalf Of Colin Dixon
Sent: Wednesday, November 06, 2013 2:45 PM
To: <affinity-dev@...>; <opendove-dev@...>; <ovsdb-dev@...>; <defense4all-dev@...>; <vtn-dev@...>
Subject: Re: [vtn-dev] Fwd: [affinity-dev] Sample Bundles in the Virtualization Edition

 

For what it's worth, I'm in the process of removing the requirements to configure SimpleFowarding so that it acts as a normal L2 switch across all the ports in the system when there's no configuration.

I'm probably the primary reason that Ed says it should do *something* when it comes up because I've been hammering like crazy on that point for the base edition. I'm not sure it's as critical here that it work immediately out of the box, but making sure that either (a) it does something without configuration when it comes up or (b) we do really good job of explaining what configuration needs to be done and give some useful error if we do nothing.

Does that seem reasonable to people?

In the long run, maybe we should talk about having a NotSoSimpleForwarding bundle that is designed to take in affinity information, virtual networks, etc. and implement them properly rather than having each different solution manage the rules on their own. This would help separate the policy from the actual routes and allow for faster innovation in both.

--Colin

> From: Hideyuki Tai <h-tai@...>
> Date: November 5, 2013 at 8:40:39 PM CST
> To: "Ed Warnicke (eaw)" <eaw@...>
> Cc: "<affinity-dev@...>" <affinity-
> dev@...>, "opendove-dev@..." <
> opendove-dev@...>, "ovsdb-dev@..." <
> ovsdb-dev@...>, "<defense4all-dev@...
> >" <defense4all-dev@...>, "vtn-dev@...
>
" <vtn-dev@...>

> Subject: RE: [affinity-dev] Sample Bundles in the Virtualization Edition

> Hi Ed,
>
> When someone runs run.sh and send some configuration to Affinity,
> OpenDOVE, or VTN,
> the Virtualization Edition does something useful.
> It requires some configuration, but it does something great related
> to virtualization.
>
> I think it's the same with simpleforwarding bundle to require configuration.
> Simpleforwarding bundle requires subnet gateway configuration to
> forward packets.
> I mean that even the Virtualization Edition include simpleforwarding,
> we need some configuration anyway.
>
> My one concern on simpleforwarding bundle is that simpleforwarding
> sets flow entries automatically
> after detecting host information.
> It means that simpleforwarding ignore virtual network configuration
> on Affinity and VTN,
> and may install flow entries which interfere with Affinity and VTN.
>
> Therefore, I would like to remove simpleforwarding bundle from the
> Virtualization Edition.
>
> Furthermore, I think simpleforwarding bundle doesn't do virtualization jobs,
> but just simulates a traditional IP network.
> So it is a little weird to me that the Virtualization Edition
> include simpleforwarding bundle.
>
> To be honest, It's not clear to me that other project in the
> Virtualization Edtion needs simpleforwarding bundle,
> or simpleforwarding bundle interfere with other bundles too.
> So I would like to hear from other project people.
>
> Regards,
> Hideyuki Tai

> -----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


Re: Collapsing topic/netty to master

Zhipeng Huang <zhipengh512@...>
 

thx, and aswin's suggestion sounds like a good idea


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

Both library and plugin are just under different package. The bundle isolation is not done yet. 
Aswin also had a suggestion to keep jsonrpc as it's own library. 

This change will be done in master soon. 

-Madhu

On Nov 6, 2013, at 7:28 PM, Zhipeng Huang <zhipengh512@...> wrote:

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
Office: Calit2 Building Room 2402



--
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: Collapsing topic/netty to master

Madhu Venugopal
 


Both library and plugin are just under different package. The bundle isolation is not done yet. 
Aswin also had a suggestion to keep jsonrpc as it's own library. 

This change will be done in master soon. 

-Madhu

On Nov 6, 2013, at 7:28 PM, Zhipeng Huang <zhipengh512@...> wrote:

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
Office: Calit2 Building Room 2402


Re: Collapsing topic/netty to master

Zhipeng Huang <zhipengh512@...>
 

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
Office: Calit2 Building Room 2402


Re: Collapsing topic/netty to master

Madhu Venugopal
 

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


Re: [affinity-dev] Sample Bundles in the Virtualization Edition

Colin Dixon <ckd@...>
 

For what it's worth, I'm in the process of removing the requirements to configure SimpleFowarding so that it acts as a normal L2 switch across all the ports in the system when there's no configuration.

I'm probably the primary reason that Ed says it should do *something* when it comes up because I've been hammering like crazy on that point for the base edition. I'm not sure it's as critical here that it work immediately out of the box, but making sure that either (a) it does something without configuration when it comes up or (b) we do really good job of explaining what configuration needs to be done and give some useful error if we do nothing.

Does that seem reasonable to people?

In the long run, maybe we should talk about having a NotSoSimpleForwarding bundle that is designed to take in affinity information, virtual networks, etc. and implement them properly rather than having each different solution manage the rules on their own. This would help separate the policy from the actual routes and allow for faster innovation in both.

--Colin

> From: Hideyuki Tai <h-tai@...>
> Date: November 5, 2013 at 8:40:39 PM CST
> To: "Ed Warnicke (eaw)" <eaw@...>
> Cc: "<affinity-dev@...>" <affinity-
> dev@...>, "opendove-dev@..." <
> opendove-dev@...>, "ovsdb-dev@..." <
> ovsdb-dev@...>, "<defense4all-dev@...
> >" <defense4all-dev@...>, "vtn-dev@...
> " <vtn-dev@...>
> Subject: RE: [affinity-dev] Sample Bundles in the Virtualization Edition

> Hi Ed,
>
> When someone runs run.sh and send some configuration to Affinity,
> OpenDOVE, or VTN,
> the Virtualization Edition does something useful.
> It requires some configuration, but it does something great related
> to virtualization.
>
> I think it's the same with simpleforwarding bundle to require configuration.
> Simpleforwarding bundle requires subnet gateway configuration to
> forward packets.
> I mean that even the Virtualization Edition include simpleforwarding,
> we need some configuration anyway.
>
> My one concern on simpleforwarding bundle is that simpleforwarding
> sets flow entries automatically
> after detecting host information.
> It means that simpleforwarding ignore virtual network configuration
> on Affinity and VTN,
> and may install flow entries which interfere with Affinity and VTN.
>
> Therefore, I would like to remove simpleforwarding bundle from the
> Virtualization Edition.
>
> Furthermore, I think simpleforwarding bundle doesn't do virtualization jobs,
> but just simulates a traditional IP network.
> So it is a little weird to me that the Virtualization Edition
> include simpleforwarding bundle.
>
> To be honest, It's not clear to me that other project in the
> Virtualization Edtion needs simpleforwarding bundle,
> or simpleforwarding bundle interfere with other bundles too.
> So I would like to hear from other project people.
>
> Regards,
> Hideyuki Tai

> -----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


Re: [controller-dev] REST-API deviation in convention (Subject renamed)

Madhu Venugopal
 

Expanding the invite to all the dev aliases.

Based on the discussion on this email thread and over IRC, we are calling for a 1+ hr webex meeting
tomorrow (11/07/2013 @ 12pm PST).
Webex details @ https://wiki.opendaylight.org/view/OpenDaylight_Controller:REST_Reference_and_Authentication:Convention
or via the events page : https://wiki.opendaylight.org/view/Events:Main#HackFests

Please participate and provide your inputs.

Thanks,
-Madhu

On 11/5/13, 7:13 AM, Madhu Venguopal wrote:
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?


Re: Collapsing topic/netty to master

Brent Salisbury
 

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


Collapsing topic/netty to master

Madhu Venugopal
 

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


Re: [affinity-dev] Sample Bundles in the Virtualization Edition

Luis Gomez <luis.gomez@...>
 

Hi all,

I have a more general question here (I cc controller dev): maybe I am missing something but why the simple forwarding application is always on in the controller (i.e. creating flows for all known hosts)? I see it is a very good use case but in my opinion it should have a turn on/off button, same as subnet gateway feature. It is not only for VTN, I am thinking on any app or consumer of the controller that may be interested in knowing the attached hosts without automatically creating flows for them.

Thanks/Luis

-----Original Message-----
From: affinity-dev-bounces@... [mailto:affinity-dev-bounces@...] On Behalf Of Hideyuki Tai
Sent: Tuesday, November 05, 2013 6:41 PM
To: Ed Warnicke (eaw)
Cc: <affinity-dev@...>; <defense4all-dev@...>; ovsdb-dev@...; opendove-dev@...; vtn-dev@...
Subject: Re: [affinity-dev] Sample Bundles in the Virtualization Edition

Hi Ed,

When someone runs run.sh and send some configuration to Affinity, OpenDOVE, or VTN,
the Virtualization Edition does something useful.
It requires some configuration, but it does something great related to virtualization.

I think it's the same with simpleforwarding bundle to require configuration.
Simpleforwarding bundle requires subnet gateway configuration to forward packets.
I mean that even the Virtualization Edition include simpleforwarding,
we need some configuration anyway.

My one concern on simpleforwarding bundle is that simpleforwarding sets flow entries automatically
after detecting host information.
It means that simpleforwarding ignore virtual network configuration on Affinity and VTN,
and may install flow entries which interfere with Affinity and VTN.

Therefore, I would like to remove simpleforwarding bundle from the Virtualization Edition.

Furthermore, I think simpleforwarding bundle doesn't do virtualization jobs,
but just simulates a traditional IP network.
So it is a little weird to me that the Virtualization Edition include simpleforwarding bundle.

To be honest, It's not clear to me that other project in the Virtualization Edtion needs simpleforwarding bundle,
or simpleforwarding bundle interfere with other bundles too.
So I would like to hear from other project people.

Regards,
Hideyuki Tai

-----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
_______________________________________________
affinity-dev mailing list
affinity-dev@...
https://lists.opendaylight.org/mailman/listinfo/affinity-dev


Re: [affinity-dev] Sample Bundles in the Virtualization Edition

Hideyuki Tai <h-tai@...>
 

Hi Ed,

When someone runs run.sh and send some configuration to Affinity, OpenDOVE, or VTN,
the Virtualization Edition does something useful.
It requires some configuration, but it does something great related to virtualization.

I think it's the same with simpleforwarding bundle to require configuration.
Simpleforwarding bundle requires subnet gateway configuration to forward packets.
I mean that even the Virtualization Edition include simpleforwarding,
we need some configuration anyway.

My one concern on simpleforwarding bundle is that simpleforwarding sets flow entries automatically
after detecting host information.
It means that simpleforwarding ignore virtual network configuration on Affinity and VTN,
and may install flow entries which interfere with Affinity and VTN.

Therefore, I would like to remove simpleforwarding bundle from the Virtualization Edition.

Furthermore, I think simpleforwarding bundle doesn't do virtualization jobs,
but just simulates a traditional IP network.
So it is a little weird to me that the Virtualization Edition include simpleforwarding bundle.

To be honest, It's not clear to me that other project in the Virtualization Edtion needs simpleforwarding bundle,
or simpleforwarding bundle interfere with other bundles too.
So I would like to hear from other project people.

Regards,
Hideyuki Tai

-----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


Re: [affinity-dev] Sample Bundles in the Virtualization Edition

Ed Warnicke (eaw) <eaw@...>
 

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


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


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


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
 

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


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