[integration-dev] Repo Location - Java OpenFlow Controller Benchmarking Tool
|
Michal Polkorab
Hello Marcus,
yes, this sounds reasonable. But I would prefer placing the tool into openflowplugin repository as: 1. there are more committers - so the development (and reviews) will be more swift, 2. openflowplugin already hosts a few applications in their repository.
By the way, are there more commits except for [1][2] ? Because I can see no dependency on openflowjava in pom.xml.
Regards, Michal
From: Williams, Marcus <marcus.williams@...>
Sent: 27 October 2015 18:36 To: openflowjava-dev@... Cc: integration-dev@...; Jamo Luhrsen Subject: [integration-dev] Repo Location - Java OpenFlow Controller Benchmarking Tool Openflowjava Devs,
Raksha has been working on a Java OpenFlow Controller Benchmarking Tool [1][2] (I’m sure many of you have seen her emails come across the wire).
The patches have been pushed to Integration/Test, mainly because that is where the tool will be utilized. It has since been noted that Integration/Test does not have infrastructure (java focused Jenkins jobs to verify/build etc.) to handle Java based patches and except for myself there are few to do reviews on Java code.
Discussion has focused on the possibility of moving the tool into the openflowjava repo, as the tool uses openflowjava as a dependency and it could be thought of as a more ‘advanced’ client using openflowjava lib.
Does this sound reasonable?
[1] https://git.opendaylight.org/gerrit/#/c/27312/ [2] https://git.opendaylight.org/gerrit/#/c/28308/
Thanks, /** Marcus */
Marcus Williams SDN Controller Team Software Defined Networking Division Network Platforms Group Intel Corporation (503) 712-6788
MichalPolkoráb Software Engineer
|
|
|
|
Marcus G K Williams
+ Openflow-dev list
Openflowplugin Devs & Committers,
Can we host a Java OpenFlow Controller Benchmarking Tool focused on testing OF 1.3 + TLS [1][2] in your repo? The patches referenced are the beginning stages of tool in question. Another patch with junit tests is forthcoming and Raksha is working on packet-in, flowmod functionality etc. now. The reasoning for moving the patches: “it has been noted that Integration/Test does not have infrastructure (java focused Jenkins jobs to verify/build etc.) to handle Java based patches and except for myself there are few to do reviews on Java code.”
Michal,
The patches that have dependency on openflowjava are in the works, though there is discussion about choosing another openflow library if the functionality we need is not present yet (it sounds like it may not be).
[1]: https://git.opendaylight.org/gerrit/#/c/27312/ [2]: https://git.opendaylight.org/gerrit/#/c/28308/
From: integration-dev-bounces@... [mailto:integration-dev-bounces@...]
On Behalf Of Michal Polkoráb
Sent: Wednesday, October 28, 2015 2:47 AM To: Williams, Marcus <marcus.williams@...>; openflowjava-dev@... Cc: integration-dev@...; Jamo Luhrsen <jluhrsen@...> Subject: Re: [integration-dev] Repo Location - Java OpenFlow Controller Benchmarking Tool
Hello Marcus,
yes, this sounds reasonable. But I would prefer placing the tool into openflowplugin repository as: 1. there are more committers - so the development (and reviews) will be more swift, 2. openflowplugin already hosts a few applications in their repository.
By the way, are there more commits except for [1][2] ? Because I can see no dependency on openflowjava in pom.xml.
Regards, Michal
From: Williams, Marcus <marcus.williams@...>
Openflowjava Devs,
Raksha has been working on a Java OpenFlow Controller Benchmarking Tool [1][2] (I’m sure many of you have seen her emails come across the wire).
The patches have been pushed to Integration/Test, mainly because that is where the tool will be utilized. It has since been noted that Integration/Test does not have infrastructure (java focused Jenkins jobs to verify/build etc.) to handle Java based patches and except for myself there are few to do reviews on Java code.
Discussion has focused on the possibility of moving the tool into the openflowjava repo, as the tool uses openflowjava as a dependency and it could be thought of as a more ‘advanced’ client using openflowjava lib.
Does this sound reasonable?
[1] https://git.opendaylight.org/gerrit/#/c/27312/ [2] https://git.opendaylight.org/gerrit/#/c/28308/
Thanks, /** Marcus */
Marcus Williams SDN Controller Team Software Defined Networking Division Network Platforms Group Intel Corporation (503) 712-6788
MichalPolkoráb Software Engineer
|
|
|
|
Abhijit Kumbhare
Sure - I don't see any issue with that. As Michal mentioned - we already host several OpenFlow related apps. These apps or what were initially called the NSFs (forwarding rules manager, stats mgr, inventory mgr, topology mgr, etc.) had been discussed with/approved at the TSC earlier in the year. Also the following is in scope of the project & your OpenFlow controller benchmarking tool can be considered under that scope:
On Wed, Oct 28, 2015 at 10:48 AM, Williams, Marcus <marcus.williams@...> wrote:
|
|
|
|
Luis Gomez <ecelgp@...>
Thanks Abhijit for hosting this :)
|
|
|
|
Abhijit Kumbhare
No problems :)
toggle quoted messageShow quoted text
On Wednesday, October 28, 2015, Luis Gomez <ecelgp@...> wrote:
|
|
|
