Hi team, I have a question regarding Jenkins setup: if I create a branch in our git repo for new test code (Python or Robot) stored under “testcode” folder or I create a branch in our git repo

Hi Ryan, that’s precisely why we call them external apps. The question for you maybe is whether you would like to have OpenDove external apps included in the OpenDaylight release (like VTN people),

That might be a little difficult as the external apps for OpenDove aren't even intended to be run on the same appliance or physical host as the controller. Ryan Luis Gomez ---11/05/2013 11:36:19

Yes I agree, we have currently 3 projects with external apps: VTN, OpenDove and Defense4all (cc-ing them as well). It would be good to come up with a common or similar way of packaging these

Ed- ACK - Packaging the openDOVE external bits is a big checkoff item on both Anees and my checklists. Ryan "Ed Warnicke (eaw)" ---11/05/2013 09:22:53 AM---Luis, VTN Coordinator is a part of the

Luis, VTN Coordinator is a part of the Virtualization Edition. It, like Defense4All, is an app that runs outside the controller. We should figure out how we want to package them. Here’s one

Hideyuki, We do intend to include the VTN Coordinator, and just hadn’t worked out the correct way to do so yet. What would your suggestion be? Ed

Hi Luis Thanks for your willing to help test the code. Currently, we've finished the tests on main functions of all modules in the base edition. We believe there's still lots of work to do

Hi Hideyuki, My understanding (Ed, correct me if I am wrong) is that, so far and for integration purposes, we are only packaging what is in the controller instance and NOT what is in the overall

Hi all, The release deliverable of VTN Project consists of VTN Manager and VTN Coordinator. Both of them will be included in the Virtualization Edition for Hydrogen. => See page 21 of OpenDaylight

Hi Moiz, See my answers inline:

Hi Guys, A couple of questions on the System test. a. Will the System Test be integrated with the build? b. What framework are we going to use to deploy the built artifacts? Is it going to be

Thanks denghui! Can you also help test the topology_manager, where I put a test_userlink_operations() but it fails sometime. So glad to see we already finish the framework and input the tests on

Hi baohua I test do_put_request, it works, and i add a example for put request in restlib. All changes i push to github. please check it. thanks. 2013/11/2 Gmail <yangbaohua@...>

OK, I changed the test case order so that we start with the most basic services and end with most abstracted services : - Switch Mgr - Topology Mgr - FRM -

Sure. Integration with the robot framework is our next step. We certainly consider the scalability. Currently, we need to finish all test cases on each module ASAP. Denghui, can you finish reviewing

Hi baohua I review all cases you commit, they are great. Since in the future, we will reuse all those cases to integrate with robot framework, So, i have a comment. we need to make sure file

Sure, Luis. This is a valuable question! IMHO, the simple-to-complex order is good. However, we might also keep test cases independent from each other, i.e., each test case should be self-complete.

BTW, I think I would prefer some logic in the order like (simple to complex) and independent modules even it this means more TCs. BR/Luis

Hi Baohua and all, I have also observed the list of TCs in the Base Test Plan has been reordered following alphabetical order. This is fine but I just want to explain the reason for the order