Br208 #211
Br208 #211
Conversation
|
@kthare10 - Are all of the new tests getting successfully run? I ask b/c the number of tests goes from 111 down to 104, indicating that perhaps 7 tests were not run, and I'm unsure if this is relevant to what you were wanting to solve... Reference: Jenkins run 8 as failed (111 tests - regressions 22-29 failing): https://ci.exogeni.net:8443/job/ORCA5Temp/8/orca.controllers$xmlrpc/testReport/orca.controllers.xmlrpc/OrcaRegressionModifyTest/ Jenkins run 9 as passed (104 tests - regression 22 fixed, no further regressions shown (23-29?)): https://ci.exogeni.net:8443/job/ORCA5Temp/9/orca.controllers$xmlrpc/testReport/orca.controllers.xmlrpc/OrcaRegressionModifyTest/ |
|
All the tests run successfully in Build#9. The original Regression Modify Tests class allowed only one modify request, so i had defined 8 test cases to verify 8 modify operations which worked as Create + Modify. But later changed Regression tests to verify Create + 8 modify requests in a single test case which matches the Issue#208 . |
|
Looks good to me. |
|
Merge it, cut a new release. |
Issue#208: When 3 or more VLANs are added to a Node via multiple Modify Slice Requests, at least one network interface would not be created on the VM.
Code Details
OrcaXmlRpcHandler::modifySlice invokes ReservationConverter::modifyReservations to build the local properties for the newly added VLANs. ReservationConverter::modifyReservations logic to construct the information for network devices was working incorrectly and always did not construct appropriate information for at least one interface. This results in modify command for at least one network interface to be not sent to the AM and hence causing missing network on VM.
Reason for Properties to be not constructed for at least one interface:
ReservationConverter::modifyReservations constructs network interface properties by traversing a linked list of network elements(existing and new). Linked List does not maintain the order of the Network elements. Thus new network elements are not processed after existing elements have been processed. modifyReservations generates the eth name for the new network element using local property unit.number.interface. In the existing code this property always had value 0 thus resulting in already used eth names and causing data for at least one interface to be overwritten.
Fix:
Stored unit.number.interface in configuration properties and used it for subsequent modifies. unit.number.interface value is not decremented in case of a deletion to keep the eth names unique.