Date   

Re: hacking around

Madhu Venugopal (vmadhu) <vmadhu@...>
 

Hi,

The OVSDB infrastructure code is undergoing a major revamp.
  1. We are moving away from jsonrpc4j towards netty based custom 2-way JSON-RPC implementation.
  2. Moving away from String and custom message parsing towards Jackson Marshalling/Demarshalling to POJOs directly.
  3. Better Monitor / Update handling
  4. Protocol Library / Plugin separation.
Hacking with the current existing code will be rendered unusable soon.
So, I would suggest to hold off on that.

If you are interested in contributing to any of the above topics, please let me know.

Thanks,
Madhu

From: Zhipeng Huang <zhipengh512@...>
Date: Thursday, September 19, 2013 10:07 AM
To: "ovsdb-dev@..." <ovsdb-dev@...>
Subject: [ovsdb-dev] hacking around

Hi, I've successfully build ovsdb, is there a guide for hack around the code?

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


hacking around

Zhipeng Huang <zhipengh512@...>
 

Hi, I've successfully build ovsdb, is there a guide for hack around the code?

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


Integration collaboration

Luis Gomez <luis.gomez@...>
 

Hi ovsdb developers,

 

In case you do not know we have created a new project in OpenDaylight with the goal of coordinating release, integration and test efforts across all projects.

 

The project has already gathered a few people willing to collaborate, however as I stated on the last week Hackfest: we have a strong dependency on the other projects, this is we cannot do much without your support.

 

In particular we need a contact (at least one) person in your team who can:

 

1) Sign-up the vHackfest proposed by Ed (see below) so that we are sure we fulfill M3 Continuous Integration Test Start requirement. Note this is IMMEDIATE need (by tomorrow).

2) Answer general questions about test procedures and quality regarding your project

3) Provide a high-level overview of your deliverable features (especially those subject to test) so that we can have a consistent release and also better plan for the final tests

 

I hope I hear from you very soon

 

Thanks in advance

/Luis

 

 

From: discuss-bounces@... [mailto:discuss-bounces@...] On Behalf Of Ed Warnicke (eaw)
Sent: Sunday, September 15, 2013 6:27 PM
To: discuss@...
Subject: Re: [OpenDaylight Discuss] Integration vHackfest Next Week

 

I've put up a page for the vHackFest here:

 

 

Please make sure at least one person from each project signs up there

to participate in the vHackFest on Thursday no later than Mon Sept 16 so we can all meet the M3 Continuous Integration

Test Start requirement.

 

Ed

On Sep 12, 2013, at 7:11 PM, Ed Warnicke (eaw) <eaw@...> wrote:

 

According to the Hydrogen Release Plan:

https://wiki.opendaylight.org/view/Simultaneous_Release:Simultaneous_Release_Plan_2013

We should commence continuous integration testing no later than next week.

In order to facilitate that its been suggested we do a vHackfest next week to insure that each project:

1)  Has at least some integration testing running
2)  Has a Jenkins Job that kick off when a project it depends on changes

The basic thought is to kick off on IRC with Webex's available for screensharing/voice collaboration
over a 24 hours period (not expecting folks to stay up 24 hours… work your normal hours, but we are a
global team)  My initial thought was kicking off at

10am CEST (Rome, Brataslava) on Thu Sept 19 (aka 1am PST on Thur Sept 19)
end at
10am CEST Fri Sept 20 (aka 1am PST on Fri Sept 20)

How do those times work for folks?  Can I get at least one volunteer from each project?

Ed

_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss

 


Re: [bgpcep-dev] [openflowplugin-dev] [openflowjava-dev] [controller-dev] OF Plugin Design Updated.

Robert Varga -X (rovarga - Pantheon Technologies SRO@Cisco) <rovarga@...>
 

I suggest standardizing on 4.0.x. There has been significant API rework for the 4.0.x series. Patch to move bgpcep forward to 4.0.8 is forthcoming.

 

Bye,

Robert

 

From: bgpcep-dev-bounces@... [mailto:bgpcep-dev-bounces@...] On Behalf Of Ed Warnicke (eaw)
Sent: Friday, September 13, 2013 1:37 AM
To: Abhijit Kumbhare
Cc: Muthukumaran Kothandaraman; openflowplugin-dev@...; Christopher Price; ovsdb-dev@...; openflowjava-dev-bounces@...; openflowjava-dev@...; controller-dev@...; bgpcep-dev@...
Subject: Re: [bgpcep-dev] [openflowplugin-dev] [openflowjava-dev] [controller-dev] OF Plugin Design Updated.

 

We may want to settle onto a single version of netty throughout ODL… here's what I see so far:

 

bgpcep: 

<netty.version>4.0.7.Final</netty.version>

 

openflowjava:

 <dependency>

       <groupId>org.jboss.netty</groupId>

       <artifactId>netty</artifactId>

       <version>3.2.6.Final</version>

 </dependency>

 

ovsdb:

<dependency>

     <groupId>io.netty</groupId>

     <artifactId>netty-all</artifactId>

     <version>4.0.8.Final</version>

</dependency>

 

Ed

 

On Sep 12, 2013, at 4:38 PM, Abhijit Kumbhare <abhijitk@...>

 wrote:



The netty pipeline layout (after the version negotiation) is now a part of the OpenFlow library. They have the rough idea of the interactions with the plugin at https://wiki.opendaylight.org/view/Openflow_Protocol_Library:Main and the architecture at https://wiki.opendaylight.org/images/0/02/Openflow_Protocol_Library.pdf. I will let Tony Tkacik or Michael Rehak/Michal Polkorab answer the question with respect to the details on how the pipeline is done in the OpenFlow library.

<graycol.gif>Muthukumaran Kothandaraman ---09/12/2013 01:26:56 PM---Hi Abhijit, I think I was not quiet clear

From: Muthukumaran Kothandaraman <mkothand@...>
To: Abhijit Kumbhare/San Jose/IBM@IBMUS,
Cc: Christopher Price <christopher.price@...>, "controller-dev@..." <controller-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, openflowjava-dev-bounces@..., "openflowplugin-dev@..." <openflowplugin-dev@...>, Prasanna Huddar <prasanna.huddar@...>
Date: 09/12/2013 01:26 PM
Subject: Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated.





Hi Abhijit, 

I think I was not quiet clear


My question was primarily if we had nailed-down how this would be realized in Netty context - as Chris mentions, that cannot be overlooked as only a programming detail
because pipeline layout and their variances thereof  is the basic implementation aspect of plugin
 

Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1)
 



From:        
Abhijit Kumbhare <abhijitk@...> 
To:        
Christopher Price <christopher.price@...> 
Cc:        
"controller-dev@..." <controller-dev@...>, Muthukumaran Kothandaraman/India/IBM@IBMIN, "openflowjava-dev@..." <openflowjava-dev@...>, openflowjava-dev-bounces@..., "openflowplugin-dev@..." <openflowplugin-dev@...>, Prasanna Huddar <prasanna.huddar@...> 
Date:        
09/13/2013 01:45 AM 
Subject:        
Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated. 





The negotiation will be actually handled in the plugin - however once the negotiation is done, the version detection & switching to either the OF 1.0 or 1.3 codec will be handled in the OF library.


<graycol.gif>Christopher Price ---09/12/2013 01:09:38 PM---Adding the library dev to the thread. The negotiation decisions are policy driven through the plugin

From:
Christopher Price <christopher.price@...>
To:
Muthukumaran Kothandaraman <mkothand@...>, Prasanna Huddar <prasanna.huddar@...>,
Cc:
"openflowjava-dev@..." <openflowjava-dev@...>, "controller-dev@..." <controller-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Date:
09/12/2013 01:09 PM
Subject:
Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated.
Sent by:
openflowjava-dev-bounces@...





Adding the library dev to the thread.
The negotiation decisions are policy driven through the plugin (connection mgr (where applicable) –> plugin –> library), but the negotiation machinery and Netty aspects are library implemented.  These are good questions to come to complete clarity and agreement on!
/ Chris

From:
Muthukumaran Kothandaraman <
mkothand@...>
Date:
Thursday, September 12, 2013 12:57 PM
To:
Prasanna Huddar <
prasanna.huddar@...>
Cc:
"
controller-dev@..." <controller-dev@...>, "controller-dev-bounces@..." <controller-dev-bounces@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Subject:
Re: [controller-dev] OF Plugin Design Updated.


Hi Prasanna,

Had a few clarifications

1. Are we going with Netty 4.0x for the implementation ?
2. Do we change the Netty Channel pipeline once version-negotiation is completed ?
  More like following
 
     When 1.0 OF Header version is encountered (no need for version-negotiation)
             - Pipeline would only contain :  "ofmessage1_0decoder", "ofmessage1_0encoder", "idle", "handler"
 

     When 1.3 OF Header version is encountered
             -
Pipeline would only contain :  "ofmessage1_3decoder", "ofmessage1_3encoder", "idle", "handler"

     When 1.3 OF Header version is encountered and 1.0 is negotiated - Assuming that this case to be supported for sake of completion
             -
Pipeline would only contain :  "ofmessage1_0decoder", "ofmessage1_0encoder", "idle", "handler"

     When 1.3 OF Header version is encountered and 1.3 is negotiated - MOST LIKELY case
             -
Pipeline would only contain :  "ofmessage1_3decoder", "ofmessage1_3encoder", "idle", "handler"                

 And in order to accomplish "When 1.0/1.3 is negotiated" action, we would have a "version-detector" in all above pipeline configurations which uses only the header-version?
 



     

Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1)
 



From:        
Prasanna Huddar <prasanna.huddar@...>
To:        
"
controller-dev@..." <controller-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Date:        
09/12/2013 10:27 PM
Subject:        
[controller-dev] OF Plugin Design Updated.
Sent by:        
controller-dev-bounces@...





Hello,

           Updated the Plugin design as per the discussion in Hackfest.


https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Design


-Prasanna_______________________________________________
controller-dev mailing list

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

https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev

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

 


Re: [bgpcep-dev] [openflowplugin-dev] [openflowjava-dev] [controller-dev] OF Plugin Design Updated.

Muthukumaran Kothandaraman <mkothand@...>
 

Tony,

Not sure if the clarifications mentioned in below link have been addressed differently in the design and implementation in context of 4.0x.

Following this thread might be useful (I just posted this query)

http://stackoverflow.com/questions/18780335/netty-3-2-6-to-netty-4-0x-migration

Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1)




From:        Muthukumaran Kothandaraman/India/IBM
To:        "Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)" <ttkacik@...>
Cc:        Abhijit Kumbhare <abhijitk@...>, "bgpcep-dev@..." <bgpcep-dev@...>, Christopher Price <christopher.price@...>, "controller-dev@..." <controller-dev@...>, "Ed Warnicke (eaw)" <eaw@...>, "openflowjava-dev@..." <openflowjava-dev@...>, "openflowjava-dev-bounces@..." <openflowjava-dev-bounces@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>
Date:        09/13/2013 05:30 AM
Subject:        RE: [bgpcep-dev] [openflowplugin-dev] [openflowjava-dev]        [controller-dev] OF        Plugin Design Updated.



It would be better to go for latest version as suggested by Tony. We might want to look into the following resolutions just in case https://issues.jboss.org/issues/?jql=project%20%3D%20NETTY%20AND%20fixVersion%20%3D%20%224.0.0.x%22%20AND%20status%20%3D%20Resolved%20ORDER%20BY%20priority%20DESC

Earlier, for protocol-plugin and codec  I had used 3.2.6 because of the stability, drastically different 4.0x API , wider mindshare of experience in forums on 3.2.6 and documentation.
If we account and contain Netty dependencies to limited classes, changing to newer version would not be an issue.

Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1)





From:        "Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)" <ttkacik@...>
To:        "Ed Warnicke (eaw)" <eaw@...>, Abhijit Kumbhare <abhijitk@...>
Cc:        Muthukumaran Kothandaraman/India/IBM@IBMIN, "openflowplugin-dev@..." <openflowplugin-dev@...>, Christopher Price <christopher.price@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "openflowjava-dev-bounces@..." <openflowjava-dev-bounces@...>, "openflowjava-dev@..." <openflowjava-dev@...>, "controller-dev@..." <controller-dev@...>, "bgpcep-dev@..." <bgpcep-dev@...>
Date:        09/13/2013 05:11 AM
Subject:        RE: [bgpcep-dev] [openflowplugin-dev] [openflowjava-dev]        [controller-dev] OF        Plugin Design Updated.




I would suggest using Netty 4.0.9-Final
Still in distribution you could overrride minor number.
 
Tony
 
 
From: bgpcep-dev-bounces@... [mailto:bgpcep-dev-bounces@...] On Behalf Of Ed Warnicke (eaw)
Sent:
Thursday, September 12, 2013 4:37 PM
To:
Abhijit Kumbhare
Cc:
Muthukumaran Kothandaraman; openflowplugin-dev@...; Christopher Price; ovsdb-dev@...; openflowjava-dev-bounces@...; openflowjava-dev@...; controller-dev@...; bgpcep-dev@...
Subject:
Re: [bgpcep-dev] [openflowplugin-dev] [openflowjava-dev] [controller-dev] OF Plugin Design Updated.

 
We may want to settle onto a single version of netty throughout ODL… here's what I see so far:
 
bgpcep:
https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pom.xml;h=c85d766e94a6b9ad73bd831b0d79bd07dcddc205;hb=HEAD
<netty.version>4.0.7.Final</netty.version>
 
openflowjava:
https://git.opendaylight.org/gerrit/gitweb?p=openflowjava.git;a=blob;f=third-party/openflowj_netty/pom.xml;h=379c6197737bc697da2d4ef685cccdbfc9024fa1;hb=HEAD
 <dependency>
       <groupId>org.jboss.netty</groupId>
       <artifactId>netty</artifactId>
       <version>3.2.6.Final</version>
 </dependency>
 
ovsdb:
https://git.opendaylight.org/gerrit/gitweb?p=ovsdb.git;a=blob;f=ovsdb/pom.xml;h=904febb3fdfdc9df371819f381b3620be3ab3a36;hb=b5688d33619e1a3b11af5ba9d1c8e7b0cacf59e1
<dependency>
     <groupId>io.netty</groupId>
     <artifactId>netty-all</artifactId>
     <version>4.0.8.Final</version>
</dependency>
 
Ed
 
On Sep 12, 2013, at 4:38 PM, Abhijit Kumbhare <abhijitk@...>
 wrote:

The netty pipeline layout (after the version negotiation) is now a part of the OpenFlow library. They have the rough idea of the interactions with the plugin at https://wiki.opendaylight.org/view/Openflow_Protocol_Library:Main and the architecture at https://wiki.opendaylight.org/images/0/02/Openflow_Protocol_Library.pdf. I will let Tony Tkacik or Michael Rehak/Michal Polkorab answer the question with respect to the details on how the pipeline is done in the OpenFlow library.

<graycol.gif>
Muthukumaran Kothandaraman ---09/12/2013 01:26:56 PM---Hi Abhijit, I think I was not quiet clear

From:
Muthukumaran Kothandaraman <mkothand@...>
To:
Abhijit Kumbhare/San Jose/IBM@IBMUS,
Cc:
Christopher Price <christopher.price@...>, "controller-dev@..." <controller-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, openflowjava-dev-bounces@..., "openflowplugin-dev@..." <openflowplugin-dev@...>, Prasanna Huddar <prasanna.huddar@...>
Date:
09/12/2013 01:26 PM
Subject:
Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated.






Hi Abhijit,


I think I was not quiet clear

My question was primarily if we had nailed-down how this would be realized in Netty context - as Chris mentions, that cannot be overlooked as only a programming detail
because pipeline layout and their variances thereof  is the basic implementation aspect of plugin


Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1)




From:        
Abhijit Kumbhare <abhijitk@...>
To:        
Christopher Price <christopher.price@...>
Cc:        
"controller-dev@..." <controller-dev@...>, Muthukumaran Kothandaraman/India/IBM@IBMIN, "openflowjava-dev@..." <openflowjava-dev@...>, openflowjava-dev-bounces@..., "openflowplugin-dev@..." <openflowplugin-dev@...>, Prasanna Huddar <prasanna.huddar@...>
Date:        
09/13/2013 01:45 AM
Subject:        
Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated.





The negotiation will be actually handled in the plugin - however once the negotiation is done, the version detection & switching to either the OF 1.0 or 1.3 codec will be handled in the OF library.


<graycol.gif>
Christopher Price ---09/12/2013 01:09:38 PM---Adding the library dev to the thread. The negotiation decisions are policy driven through the plugin

From:
Christopher Price <christopher.price@...>
To:
Muthukumaran Kothandaraman <mkothand@...>, Prasanna Huddar <prasanna.huddar@...>,
Cc:
"openflowjava-dev@..." <openflowjava-dev@...>, "controller-dev@..." <controller-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Date:
09/12/2013 01:09 PM
Subject:
Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated.
Sent by:
openflowjava-dev-bounces@...





Adding the library dev to the thread.
The negotiation decisions are policy driven through the plugin (connection mgr (where applicable) –> plugin –> library), but the negotiation machinery and Netty aspects are library implemented.  These are good questions to come to complete clarity and agreement on!
/ Chris

From:
Muthukumaran Kothandaraman <
mkothand@...>
Date:
Thursday, September 12, 2013 12:57 PM
To:
Prasanna Huddar <
prasanna.huddar@...>
Cc:
"
controller-dev@..." <controller-dev@...>, "controller-dev-bounces@..." <controller-dev-bounces@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Subject:
Re: [controller-dev] OF Plugin Design Updated.


Hi Prasanna,

Had a few clarifications

1. Are we going with Netty 4.0x for the implementation ?
2. Do we change the Netty Channel pipeline once version-negotiation is completed ?
 More like following

    When 1.0 OF Header version is encountered (no need for version-negotiation)
            - Pipeline would only contain :  
"ofmessage1_0decoder", "ofmessage1_0encoder", "idle", "handler"

    When 1.3 OF Header version is encountered

            -
Pipeline would only contain :  "ofmessage1_3decoder", "ofmessage1_3encoder", "idle", "handler"

    When 1.3 OF Header version is encountered and 1.0 is negotiated - Assuming that this case to be supported for sake of completion

            -
Pipeline would only contain :  "ofmessage1_0decoder", "ofmessage1_0encoder", "idle", "handler"

    When 1.3 OF Header version is encountered and 1.3 is negotiated - MOST LIKELY case

            -
Pipeline would only contain :  "ofmessage1_3decoder", "ofmessage1_3encoder", "idle", "handler"                

And in order to accomplish "When 1.0/1.3 is negotiated" action, we would have a "
version-detector" in all above pipeline configurations which uses only the header-version?



   

Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1)




From:        
Prasanna Huddar <prasanna.huddar@...>
To:        
"controller-dev@..." <controller-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Date:        
09/12/2013 10:27 PM
Subject:        
[controller-dev] OF Plugin Design Updated.
Sent by:        
controller-dev-bounces@...





Hello,

          Updated the Plugin design as per the discussion in Hackfest.


https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Design


-Prasanna_______________________________________________
controller-dev mailing list

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

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

openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
 


Re: [bgpcep-dev] [openflowplugin-dev] [openflowjava-dev] [controller-dev] OF Plugin Design Updated.

Muthukumaran Kothandaraman <mkothand@...>
 

It would be better to go for latest version as suggested by Tony. We might want to look into the following resolutions just in case https://issues.jboss.org/issues/?jql=project%20%3D%20NETTY%20AND%20fixVersion%20%3D%20%224.0.0.x%22%20AND%20status%20%3D%20Resolved%20ORDER%20BY%20priority%20DESC

Earlier, for protocol-plugin and codec  I had used 3.2.6 because of the stability, drastically different 4.0x API , wider mindshare of experience in forums on 3.2.6 and documentation.
If we account and contain Netty dependencies to limited classes, changing to newer version would not be an issue.

Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1)




From:        "Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)" <ttkacik@...>
To:        "Ed Warnicke (eaw)" <eaw@...>, Abhijit Kumbhare <abhijitk@...>
Cc:        Muthukumaran Kothandaraman/India/IBM@IBMIN, "openflowplugin-dev@..." <openflowplugin-dev@...>, Christopher Price <christopher.price@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "openflowjava-dev-bounces@..." <openflowjava-dev-bounces@...>, "openflowjava-dev@..." <openflowjava-dev@...>, "controller-dev@..." <controller-dev@...>, "bgpcep-dev@..." <bgpcep-dev@...>
Date:        09/13/2013 05:11 AM
Subject:        RE: [bgpcep-dev] [openflowplugin-dev] [openflowjava-dev]        [controller-dev] OF        Plugin Design Updated.




I would suggest using Netty 4.0.9-Final
Still in distribution you could overrride minor number.
 
Tony
 
 
From: bgpcep-dev-bounces@... [mailto:bgpcep-dev-bounces@...] On Behalf Of Ed Warnicke (eaw)
Sent:
Thursday, September 12, 2013 4:37 PM
To:
Abhijit Kumbhare
Cc:
Muthukumaran Kothandaraman; openflowplugin-dev@...; Christopher Price; ovsdb-dev@...; openflowjava-dev-bounces@...; openflowjava-dev@...; controller-dev@...; bgpcep-dev@...
Subject:
Re: [bgpcep-dev] [openflowplugin-dev] [openflowjava-dev] [controller-dev] OF Plugin Design Updated.

 
We may want to settle onto a single version of netty throughout ODL… here's what I see so far:
 
bgpcep:
https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pom.xml;h=c85d766e94a6b9ad73bd831b0d79bd07dcddc205;hb=HEAD
<netty.version>4.0.7.Final</netty.version>
 
openflowjava:
https://git.opendaylight.org/gerrit/gitweb?p=openflowjava.git;a=blob;f=third-party/openflowj_netty/pom.xml;h=379c6197737bc697da2d4ef685cccdbfc9024fa1;hb=HEAD
 <dependency>
       <groupId>org.jboss.netty</groupId>
       <artifactId>netty</artifactId>
       <version>3.2.6.Final</version>
 </dependency>
 
ovsdb:
https://git.opendaylight.org/gerrit/gitweb?p=ovsdb.git;a=blob;f=ovsdb/pom.xml;h=904febb3fdfdc9df371819f381b3620be3ab3a36;hb=b5688d33619e1a3b11af5ba9d1c8e7b0cacf59e1
<dependency>
     <groupId>io.netty</groupId>
     <artifactId>netty-all</artifactId>
     <version>4.0.8.Final</version>
</dependency>
 
Ed
 
On Sep 12, 2013, at 4:38 PM, Abhijit Kumbhare <abhijitk@...>
 wrote:

The netty pipeline layout (after the version negotiation) is now a part of the OpenFlow library. They have the rough idea of the interactions with the plugin at https://wiki.opendaylight.org/view/Openflow_Protocol_Library:Main and the architecture at https://wiki.opendaylight.org/images/0/02/Openflow_Protocol_Library.pdf. I will let Tony Tkacik or Michael Rehak/Michal Polkorab answer the question with respect to the details on how the pipeline is done in the OpenFlow library.

<graycol.gif>
Muthukumaran Kothandaraman ---09/12/2013 01:26:56 PM---Hi Abhijit, I think I was not quiet clear

From:
Muthukumaran Kothandaraman <mkothand@...>
To:
Abhijit Kumbhare/San Jose/IBM@IBMUS,
Cc:
Christopher Price <christopher.price@...>, "controller-dev@..." <controller-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, openflowjava-dev-bounces@..., "openflowplugin-dev@..." <openflowplugin-dev@...>, Prasanna Huddar <prasanna.huddar@...>
Date:
09/12/2013 01:26 PM
Subject:
Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated.






Hi Abhijit,


I think I was not quiet clear

My question was primarily if we had nailed-down how this would be realized in Netty context - as Chris mentions, that cannot be overlooked as only a programming detail
because pipeline layout and their variances thereof  is the basic implementation aspect of plugin


Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1)




From:        
Abhijit Kumbhare <abhijitk@...>
To:        
Christopher Price <christopher.price@...>
Cc:        
"controller-dev@..." <controller-dev@...>, Muthukumaran Kothandaraman/India/IBM@IBMIN, "openflowjava-dev@..." <openflowjava-dev@...>, openflowjava-dev-bounces@..., "openflowplugin-dev@..." <openflowplugin-dev@...>, Prasanna Huddar <prasanna.huddar@...>
Date:        
09/13/2013 01:45 AM
Subject:        
Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated.





The negotiation will be actually handled in the plugin - however once the negotiation is done, the version detection & switching to either the OF 1.0 or 1.3 codec will be handled in the OF library.


<graycol.gif>
Christopher Price ---09/12/2013 01:09:38 PM---Adding the library dev to the thread. The negotiation decisions are policy driven through the plugin

From:
Christopher Price <christopher.price@...>
To:
Muthukumaran Kothandaraman <mkothand@...>, Prasanna Huddar <prasanna.huddar@...>,
Cc:
"openflowjava-dev@..." <openflowjava-dev@...>, "controller-dev@..." <controller-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Date:
09/12/2013 01:09 PM
Subject:
Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated.
Sent by:
openflowjava-dev-bounces@...





Adding the library dev to the thread.
The negotiation decisions are policy driven through the plugin (connection mgr (where applicable) –> plugin –> library), but the negotiation machinery and Netty aspects are library implemented.  These are good questions to come to complete clarity and agreement on!
/ Chris

From:
Muthukumaran Kothandaraman <
mkothand@...>
Date:
Thursday, September 12, 2013 12:57 PM
To:
Prasanna Huddar <
prasanna.huddar@...>
Cc:
"
controller-dev@..." <controller-dev@...>, "controller-dev-bounces@..." <controller-dev-bounces@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Subject:
Re: [controller-dev] OF Plugin Design Updated.


Hi Prasanna,

Had a few clarifications

1. Are we going with Netty 4.0x for the implementation ?
2. Do we change the Netty Channel pipeline once version-negotiation is completed ?
 More like following

    When 1.0 OF Header version is encountered (no need for version-negotiation)
            - Pipeline would only contain :  
"ofmessage1_0decoder", "ofmessage1_0encoder", "idle", "handler"

    When 1.3 OF Header version is encountered

            -
Pipeline would only contain :  "ofmessage1_3decoder", "ofmessage1_3encoder", "idle", "handler"

    When 1.3 OF Header version is encountered and 1.0 is negotiated - Assuming that this case to be supported for sake of completion

            -
Pipeline would only contain :  "ofmessage1_0decoder", "ofmessage1_0encoder", "idle", "handler"

    When 1.3 OF Header version is encountered and 1.3 is negotiated - MOST LIKELY case

            -
Pipeline would only contain :  "ofmessage1_3decoder", "ofmessage1_3encoder", "idle", "handler"                

And in order to accomplish "When 1.0/1.3 is negotiated" action, we would have a "
version-detector" in all above pipeline configurations which uses only the header-version?



   

Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1)




From:        
Prasanna Huddar <prasanna.huddar@...>
To:        
"controller-dev@..." <controller-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Date:        
09/12/2013 10:27 PM
Subject:        
[controller-dev] OF Plugin Design Updated.
Sent by:        
controller-dev-bounces@...





Hello,

          Updated the Plugin design as per the discussion in Hackfest.


https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Design


-Prasanna_______________________________________________
controller-dev mailing list

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

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

openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
 


Re: [bgpcep-dev] [openflowplugin-dev] [openflowjava-dev] [controller-dev] OF Plugin Design Updated.

Tony Tkacik -X (ttkacik - Pantheon Technologies SRO@Cisco) <ttkacik@...>
 

I would suggest using Netty 4.0.9-Final

Still in distribution you could overrride minor number.

 

Tony

 

 

From: bgpcep-dev-bounces@... [mailto:bgpcep-dev-bounces@...] On Behalf Of Ed Warnicke (eaw)
Sent: Thursday, September 12, 2013 4:37 PM
To: Abhijit Kumbhare
Cc: Muthukumaran Kothandaraman; openflowplugin-dev@...; Christopher Price; ovsdb-dev@...; openflowjava-dev-bounces@...; openflowjava-dev@...; controller-dev@...; bgpcep-dev@...
Subject: Re: [bgpcep-dev] [openflowplugin-dev] [openflowjava-dev] [controller-dev] OF Plugin Design Updated.

 

We may want to settle onto a single version of netty throughout ODL… here's what I see so far:

 

bgpcep: 

<netty.version>4.0.7.Final</netty.version>

 

openflowjava:

 <dependency>

       <groupId>org.jboss.netty</groupId>

       <artifactId>netty</artifactId>

       <version>3.2.6.Final</version>

 </dependency>

 

ovsdb:

<dependency>

     <groupId>io.netty</groupId>

     <artifactId>netty-all</artifactId>

     <version>4.0.8.Final</version>

</dependency>

 

Ed

 

On Sep 12, 2013, at 4:38 PM, Abhijit Kumbhare <abhijitk@...>

 wrote:



The netty pipeline layout (after the version negotiation) is now a part of the OpenFlow library. They have the rough idea of the interactions with the plugin at https://wiki.opendaylight.org/view/Openflow_Protocol_Library:Main and the architecture at https://wiki.opendaylight.org/images/0/02/Openflow_Protocol_Library.pdf. I will let Tony Tkacik or Michael Rehak/Michal Polkorab answer the question with respect to the details on how the pipeline is done in the OpenFlow library.

<graycol.gif>Muthukumaran Kothandaraman ---09/12/2013 01:26:56 PM---Hi Abhijit, I think I was not quiet clear

From: Muthukumaran Kothandaraman <mkothand@...>
To: Abhijit Kumbhare/San Jose/IBM@IBMUS,
Cc: Christopher Price <christopher.price@...>, "controller-dev@..." <controller-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, openflowjava-dev-bounces@..., "openflowplugin-dev@..." <openflowplugin-dev@...>, Prasanna Huddar <prasanna.huddar@...>
Date: 09/12/2013 01:26 PM
Subject: Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated.





Hi Abhijit, 

I think I was not quiet clear


My question was primarily if we had nailed-down how this would be realized in Netty context - as Chris mentions, that cannot be overlooked as only a programming detail
because pipeline layout and their variances thereof  is the basic implementation aspect of plugin
 

Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1)
 



From:        
Abhijit Kumbhare <abhijitk@...> 
To:        
Christopher Price <christopher.price@...> 
Cc:        
"controller-dev@..." <controller-dev@...>, Muthukumaran Kothandaraman/India/IBM@IBMIN, "openflowjava-dev@..." <openflowjava-dev@...>, openflowjava-dev-bounces@..., "openflowplugin-dev@..." <openflowplugin-dev@...>, Prasanna Huddar <prasanna.huddar@...> 
Date:        
09/13/2013 01:45 AM 
Subject:        
Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated. 





The negotiation will be actually handled in the plugin - however once the negotiation is done, the version detection & switching to either the OF 1.0 or 1.3 codec will be handled in the OF library.


<graycol.gif>Christopher Price ---09/12/2013 01:09:38 PM---Adding the library dev to the thread. The negotiation decisions are policy driven through the plugin

From:
Christopher Price <christopher.price@...>
To:
Muthukumaran Kothandaraman <mkothand@...>, Prasanna Huddar <prasanna.huddar@...>,
Cc:
"openflowjava-dev@..." <openflowjava-dev@...>, "controller-dev@..." <controller-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Date:
09/12/2013 01:09 PM
Subject:
Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated.
Sent by:
openflowjava-dev-bounces@...





Adding the library dev to the thread.
The negotiation decisions are policy driven through the plugin (connection mgr (where applicable) –> plugin –> library), but the negotiation machinery and Netty aspects are library implemented.  These are good questions to come to complete clarity and agreement on!
/ Chris

From:
Muthukumaran Kothandaraman <
mkothand@...>
Date:
Thursday, September 12, 2013 12:57 PM
To:
Prasanna Huddar <
prasanna.huddar@...>
Cc:
"
controller-dev@..." <controller-dev@...>, "controller-dev-bounces@..." <controller-dev-bounces@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Subject:
Re: [controller-dev] OF Plugin Design Updated.


Hi Prasanna,

Had a few clarifications

1. Are we going with Netty 4.0x for the implementation ?
2. Do we change the Netty Channel pipeline once version-negotiation is completed ?
  More like following
 
     When 1.0 OF Header version is encountered (no need for version-negotiation)
             - Pipeline would only contain :  "ofmessage1_0decoder", "ofmessage1_0encoder", "idle", "handler"
 

     When 1.3 OF Header version is encountered
             -
Pipeline would only contain :  "ofmessage1_3decoder", "ofmessage1_3encoder", "idle", "handler"

     When 1.3 OF Header version is encountered and 1.0 is negotiated - Assuming that this case to be supported for sake of completion
             -
Pipeline would only contain :  "ofmessage1_0decoder", "ofmessage1_0encoder", "idle", "handler"

     When 1.3 OF Header version is encountered and 1.3 is negotiated - MOST LIKELY case
             -
Pipeline would only contain :  "ofmessage1_3decoder", "ofmessage1_3encoder", "idle", "handler"                

 And in order to accomplish "When 1.0/1.3 is negotiated" action, we would have a "version-detector" in all above pipeline configurations which uses only the header-version?
 



     

Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1)
 



From:        
Prasanna Huddar <prasanna.huddar@...>
To:        
"
controller-dev@..." <controller-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Date:        
09/12/2013 10:27 PM
Subject:        
[controller-dev] OF Plugin Design Updated.
Sent by:        
controller-dev-bounces@...





Hello,

           Updated the Plugin design as per the discussion in Hackfest.


https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Design


-Prasanna_______________________________________________
controller-dev mailing list

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

https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev

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

 


Re: [openflowplugin-dev] [openflowjava-dev] [controller-dev] OF Plugin Design Updated.

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

We may want to settle onto a single version of netty throughout ODL… here's what I see so far:

bgpcep: 
<netty.version>4.0.7.Final</netty.version>

openflowjava:
 <dependency>
       <groupId>org.jboss.netty</groupId>
       <artifactId>netty</artifactId>
       <version>3.2.6.Final</version>
 </dependency>

ovsdb:
<dependency>
     <groupId>io.netty</groupId>
     <artifactId>netty-all</artifactId>
     <version>4.0.8.Final</version>
</dependency>

Ed

On Sep 12, 2013, at 4:38 PM, Abhijit Kumbhare <abhijitk@...>
 wrote:

The netty pipeline layout (after the version negotiation) is now a part of the OpenFlow library. They have the rough idea of the interactions with the plugin at https://wiki.opendaylight.org/view/Openflow_Protocol_Library:Main and the architecture at https://wiki.opendaylight.org/images/0/02/Openflow_Protocol_Library.pdf. I will let Tony Tkacik or Michael Rehak/Michal Polkorab answer the question with respect to the details on how the pipeline is done in the OpenFlow library.

<graycol.gif>Muthukumaran Kothandaraman ---09/12/2013 01:26:56 PM---Hi Abhijit, I think I was not quiet clear

From: Muthukumaran Kothandaraman <mkothand@...>
To: Abhijit Kumbhare/San Jose/IBM@IBMUS,
Cc: Christopher Price <christopher.price@...>, "controller-dev@..." <controller-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, openflowjava-dev-bounces@..., "openflowplugin-dev@..." <openflowplugin-dev@...>, Prasanna Huddar <prasanna.huddar@...>
Date: 09/12/2013 01:26 PM
Subject: Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated.





Hi Abhijit, 

I think I was not quiet clear


My question was primarily if we had nailed-down how this would be realized in Netty context - as Chris mentions, that cannot be overlooked as only a programming detail
because pipeline layout and their variances thereof  is the basic implementation aspect of plugin
 

Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1)
 



From:        
Abhijit Kumbhare <abhijitk@...> 
To:        
Christopher Price <christopher.price@...> 
Cc:        
"controller-dev@..." <controller-dev@...>, Muthukumaran Kothandaraman/India/IBM@IBMIN, "openflowjava-dev@..." <openflowjava-dev@...>, openflowjava-dev-bounces@..., "openflowplugin-dev@..." <openflowplugin-dev@...>, Prasanna Huddar <prasanna.huddar@...> 
Date:        
09/13/2013 01:45 AM 
Subject:        
Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated. 




The negotiation will be actually handled in the plugin - however once the negotiation is done, the version detection & switching to either the OF 1.0 or 1.3 codec will be handled in the OF library.


<graycol.gif>Christopher Price ---09/12/2013 01:09:38 PM---Adding the library dev to the thread. The negotiation decisions are policy driven through the plugin

From:
Christopher Price <christopher.price@...>
To:
Muthukumaran Kothandaraman <mkothand@...>, Prasanna Huddar <prasanna.huddar@...>,
Cc:
"openflowjava-dev@..." <openflowjava-dev@...>, "controller-dev@..." <controller-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Date:
09/12/2013 01:09 PM
Subject:
Re: [openflowjava-dev] [controller-dev] OF Plugin Design Updated.
Sent by:
openflowjava-dev-bounces@...




Adding the library dev to the thread.
The negotiation decisions are policy driven through the plugin (connection mgr (where applicable) –> plugin –> library), but the negotiation machinery and Netty aspects are library implemented.  These are good questions to come to complete clarity and agreement on!
/ Chris


From:
Muthukumaran Kothandaraman <mkothand@...>
Date:
Thursday, September 12, 2013 12:57 PM
To:
Prasanna Huddar <prasanna.huddar@...>
Cc:
"controller-dev@..." <controller-dev@...>, "controller-dev-bounces@..." <controller-dev-bounces@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Subject:
Re: [controller-dev] OF Plugin Design Updated.

Hi Prasanna,

Had a few clarifications

1. Are we going with Netty 4.0x for the implementation ?
2. Do we change the Netty Channel pipeline once version-negotiation is completed ?
  More like following
 
     When 1.0 OF Header version is encountered (no need for version-negotiation)
             - Pipeline would only contain :  
"ofmessage1_0decoder", "ofmessage1_0encoder", "idle", "handler" 

     When 1.3 OF Header version is encountered

             -
Pipeline would only contain :  "ofmessage1_3decoder", "ofmessage1_3encoder", "idle", "handler"

     When 1.3 OF Header version is encountered and 1.0 is negotiated - Assuming that this case to be supported for sake of completion

             -
Pipeline would only contain :  "ofmessage1_0decoder", "ofmessage1_0encoder", "idle", "handler"

     When 1.3 OF Header version is encountered and 1.3 is negotiated - MOST LIKELY case

             -
Pipeline would only contain :  "ofmessage1_3decoder", "ofmessage1_3encoder", "idle", "handler"                

 And in order to accomplish "When 1.0/1.3 is negotiated" action, we would have a "
version-detector" in all above pipeline configurations which uses only the header-version? 



     

Regards

Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1)
 



From:        
Prasanna Huddar <prasanna.huddar@...>
To:        
"controller-dev@..." <controller-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>
Date:        
09/12/2013 10:27 PM
Subject:        
[controller-dev] OF Plugin Design Updated.
Sent by:        
controller-dev-bounces@...




Hello,

           Updated the Plugin design as per the discussion in Hackfest.


https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Design


-Prasanna_______________________________________________
controller-dev mailing list

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

https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev

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


Few NorthBound REST API cleanup

Madhu Venugopal (vmadhu) <vmadhu@...>
 


Devs,

While reviewing the existing REST APIs, we identified a few inconstancies in Documentation, Grammar and URL paths.
Few of us are cleaning it up. Expect a few Gerrit review requests (all on the controller branch) in a day or 2.
These are minor changes to get the Controller REST APIs consistent and can act as a base template for any new northbound bundles.

I am writing a wiki page with all the details and developer guide on writing a consistent and effective northbound bundle.
Will keep you all posted once it is done.

Thanks,
Madhu


Distribution directory commits and Jenkin's changes

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

I pushed two changes to add a distribution directory:


https://git.opendaylight.org/gerrit/#/c/784/ - which adds the distribution directory and makes commons/ build both ovsdb/ and distribution/
https://git.opendaylight.org/gerrit/#/c/785/ - which moves commons/ to commons/parent so there's room for other 'commons' things

They both verify currently, but I would recommend if  you choose to merge them that you alter the Jenkin's Job to build the pom file:
commons/parent/pom.xml (as that should build all modules, ovsdb/ and distribution/ ).

Please also note the new top level README which has instructions analogous to what is provided in controller.

Ed



Re: [controller-dev] NetworkConfiguration -> BridgeDomain Configuration Service

Madhu Venugopal (vmadhu) <vmadhu@...>
 

>> I take it that BridgeDomains are the protocol-agnostic equivalent of an L2 segment?

Yes. That is the general idea.

Similarly, the umbrella abstraction, Network Configuration is a protocol-agnostic equivalent for any configuration in general.
(Yesterday's ethernet plugin discussion might fall under one or many sub-configuration modules).

It will certainly help to have this Terminology page in the wiki as a lookup.

Thanks,
-Madhu


From: Colin Dixon <ckd@...>
Date: Monday, August 5, 2013 6:35 PM
To: Madhu Venugopal <vmadhu@...>
Cc: "controller-dev@..." <controller-dev@...>, "controller-dev-bounces@..." <controller-dev-bounces@...>, "discuss@..." <discuss@...>, "opendove-dev@..." <opendove-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "vtn-dev@..." <vtn-dev@...>
Subject: Re: [controller-dev] NetworkConfiguration -> BridgeDomain Configuration Service

I take it that BridgeDomains are the protocol-agnostic equivalent of an L2 segment?

Should we make a wiki page somewhere of the core abstractions and their loose equivalents? It might be useful.

For example:
Node = Switch/Router/Etc
Edge = Link
NodeConnector = Nodes and edges connect, e.g., a switch port

--Colin

controller-dev-bounces@... wrote on 07/31/2013 09:51:44 AM:
> From: "Madhu Venugopal (vmadhu)" <vmadhu@...>

> To: "discuss@..." <discuss@...>
> Cc: "controller-dev@..." <controller-
> dev@...>, "ovsdb-dev@..."
> <ovsdb-dev@...>, "opendove-
> dev@..." <opendove-dev@...>,
> "vtn-dev@..." <vtn-dev@...>

> Date: 07/31/2013 09:52 AM
> Subject: [controller-dev] NetworkConfiguration -> BridgeDomain
> Configuration Service

> Sent by: controller-dev-bounces@...
>
>
> I just pushed a commit for BridgeDomain Configuration Service under the
> umbrella of SAL Network Configuration Services.
> The idea of this SAL service is to provide a Protocol Plugin agnostic way
> of configuring Bridge Domains.
> Please take a look @ http://git.opendaylight.org/gerrit/760
>
> When you browse through the code, it will be evident that, SAL
> NetworkConfiguration services are implemented as a pluggable
> bundle on its own to show the extensibility of SAL layer.
>
> Also, the NetworkConfiguration bundle is subdivided into various Services
> under their own package structure.
> We are starting this effort with the BridgeDomain management and naturally
> we can expand this and add more services under
> NetworkConfiguration bundle.
>
> Please note that the version is set as 0.0.1 to indicate that this is just
> the beginning and this code commit is to get the code flowing
> and start to integrate with network management plugins. As a start, we are
> integrating this with OVSDB plugin.
>
> The design intent is to have an extensible way of providing Network
> configuration service that satisfies various use-cases and
> various protocol plugin capabilities.
>
> Copied all the interested development lists as well.
>
> Thanks,
> Madhu
>
> _______________________________________________
> controller-dev mailing list
> controller-dev@...
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>


Re: [controller-dev] NetworkConfiguration -> BridgeDomain Configuration Service

Colin Dixon <ckd@...>
 

I take it that BridgeDomains are the protocol-agnostic equivalent of an L2 segment?

Should we make a wiki page somewhere of the core abstractions and their loose equivalents? It might be useful.

For example:
Node = Switch/Router/Etc
Edge = Link
NodeConnector = Nodes and edges connect, e.g., a switch port

--Colin

controller-dev-bounces@... wrote on 07/31/2013 09:51:44 AM:
> From: "Madhu Venugopal (vmadhu)" <vmadhu@...>

> To: "discuss@..." <discuss@...>
> Cc: "controller-dev@..." <controller-
> dev@...>, "ovsdb-dev@..."
> <ovsdb-dev@...>, "opendove-
> dev@..." <opendove-dev@...>,
> "vtn-dev@..." <vtn-dev@...>

> Date: 07/31/2013 09:52 AM
> Subject: [controller-dev] NetworkConfiguration -> BridgeDomain
> Configuration Service

> Sent by: controller-dev-bounces@...
>
>
> I just pushed a commit for BridgeDomain Configuration Service under the
> umbrella of SAL Network Configuration Services.
> The idea of this SAL service is to provide a Protocol Plugin agnostic way
> of configuring Bridge Domains.
> Please take a look @ http://git.opendaylight.org/gerrit/760
>
> When you browse through the code, it will be evident that, SAL
> NetworkConfiguration services are implemented as a pluggable
> bundle on its own to show the extensibility of SAL layer.
>
> Also, the NetworkConfiguration bundle is subdivided into various Services
> under their own package structure.
> We are starting this effort with the BridgeDomain management and naturally
> we can expand this and add more services under
> NetworkConfiguration bundle.
>
> Please note that the version is set as 0.0.1 to indicate that this is just
> the beginning and this code commit is to get the code flowing
> and start to integrate with network management plugins. As a start, we are
> integrating this with OVSDB plugin.
>
> The design intent is to have an extensible way of providing Network
> configuration service that satisfies various use-cases and
> various protocol plugin capabilities.
>
> Copied all the interested development lists as well.
>
> Thanks,
> Madhu
>
> _______________________________________________
> controller-dev mailing list
> controller-dev@...
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>


NetworkConfiguration -> BridgeDomain Configuration Service

Madhu Venugopal (vmadhu) <vmadhu@...>
 

I just pushed a commit for BridgeDomain Configuration Service under the
umbrella of SAL Network Configuration Services.
The idea of this SAL service is to provide a Protocol Plugin agnostic way
of configuring Bridge Domains.
Please take a look @ http://git.opendaylight.org/gerrit/760

When you browse through the code, it will be evident that, SAL
NetworkConfiguration services are implemented as a pluggable
bundle on its own to show the extensibility of SAL layer.

Also, the NetworkConfiguration bundle is subdivided into various Services
under their own package structure.
We are starting this effort with the BridgeDomain management and naturally
we can expand this and add more services under
NetworkConfiguration bundle.

Please note that the version is set as 0.0.1 to indicate that this is just
the beginning and this code commit is to get the code flowing
and start to integrate with network management plugins. As a start, we are
integrating this with OVSDB plugin.

The design intent is to have an extensible way of providing Network
configuration service that satisfies various use-cases and
various protocol plugin capabilities.

Copied all the interested development lists as well.

Thanks,
Madhu


Re: Jenkins setup

Andrew Grimberg <agrimberg@...>
 

Greetings folks,

Sorry about all of this. I was pretty certain that I had Maven setup
after I built out the silos before I left for my vacation. We should be
all setup now with Maven 3.0.5 for this and the other new Jenkins silos.
Apparently 3.1.0 (which is what I thought I had setup) had problems :(

-Andy-

On Mon, 2013-07-29 at 14:52 +0200, Giovanni Meo wrote:
Hi helpdesk,

i'm trying to setup the jenkins on the ovsdb project, but that fails because the
maven is not setup, here is what jenkins reports:

Jenkins needs to know where your Maven 2/3 is installed.
Please do so from the system configuration.

I know this has been reported also for the yang-tools projects, can you please
install the maven in all the jenkins instance? I'm not sure why that is needed
given maven is visible on the controller project, but seems like there is a
per-project setting missing.

Thanks in advance,
Giovanni
--
Andrew J Grimberg
Systems Administrator
The Linux Foundation


Jenkins setup

Giovanni Meo <gmeo@...>
 

Hi helpdesk,

i'm trying to setup the jenkins on the ovsdb project, but that fails because the maven is not setup, here is what jenkins reports:

Jenkins needs to know where your Maven 2/3 is installed.
Please do so from the system configuration.

I know this has been reported also for the yang-tools projects, can you please install the maven in all the jenkins instance? I'm not sure why that is needed given maven is visible on the controller project, but seems like there is a per-project setting missing.

Thanks in advance,
Giovanni
--
Giovanni Meo
Via del Serafico, 200 Telephone: +390651644000
00142, Roma Mobile: +393480700958
Italia Fax: +390651645917
VOIP: 8-3964000
“The pessimist complains about the wind;
the optimist expects it to change;
the realist adjusts the sails.” -- Wm. Arthur Ward
IETF credo: "Rough consensus and running code"

4841 - 4855 of 4855