Thanks for clarification, Luis. To Baohua, Could you share your scripts somewhere? Then people can get guidance on wiki later and also examples from somewhere. Do you think? Thanks/Guangpeng

Hi, all As discussed this morning, we've shared the developing CSIT test tool information at https://wiki.opendaylight.org/view/CrossProject:Integration_Group:Test_Tools#CSIT_Test_Tool.

Thanks Baohua, I have redesign the Test Tools area so now we have room for everything: Open Lab, CSIT Test tools, Robot, TestON, etc…

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

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

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.

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

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 -

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

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

Hi Moiz, See my answers inline:

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

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

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

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

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