> On Aug. 14, 2014, 9:54 p.m., Alena Prokharchyk wrote: > > Koushik, I did the code review and some additional testing for the process. > > Following scenarios that I've tested: > > > > * Update guest network when the network is a) implemented b) not > > implemented. > > * associate ip address list to account > > * start previously stopped router when the network is a) implemented b) not > > implemented > > * create nic for vm from the network that is a) implement b) not > > implemented. > > * deploy multiple vms for the same network in parallel (tried for 4) > > > > All test cases are tested on a real Xen setup > > > > Can you change the access to the new method from public to > > private/protected, as its an internal method, and can't be called from > > other classes? > > > > After that, please go ahead and commit your fix. Put myself as a reviewer.
Made the method as private. - Koushik ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24152/#review50653 ----------------------------------------------------------- On Aug. 5, 2014, 5:16 a.m., Koushik Das wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/24152/ > ----------------------------------------------------------- > > (Updated Aug. 5, 2014, 5:16 a.m.) > > > Review request for cloudstack, Alena Prokharchyk and Sheng Yang. > > > Bugs: CLOUDSTACK-7182 > https://issues.apache.org/jira/browse/CLOUDSTACK-7182 > > > Repository: cloudstack-git > > > Description > ------- > > - Check to see if network is implemented changed from 'state == > Implementing||Implemented' to 'state == Implemented'. The earlier check was a > hack to prevent the issue described next. > - At the time of implementing network (using implementNetwork() method), if > the VR needs to be deployed then it follows the same path of regular VM > deployment. This leads to a nested call to implementNetwork() while preparing > VR nics. This flow creates issues in dealing with network state transitions. > The original call puts network in "Implementing" state and then the nested > call again tries to put it into same state resulting in issues. In order to > avoid it, implementNetwork() call for VR is replaced with below code. > > > Diffs > ----- > > > engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java > cdca839 > > Diff: https://reviews.apache.org/r/24152/diff/ > > > Testing > ------- > > 1. Ran the network related tests under /test/integration/smoke folder using > Simulator. Also the other smoke tests didn’t cause any new failures. > > 2. Also ran the following VPC test using simulator: > a. created vpc, VR gets started as part of this > b. created network in the vpc > c. deployed vm in network created in step#2 > > 3. Manually ran the following tests using simulator (for both regular VR and > VPC VR): > a. VR stop/start via API when the network is in Implemented state. Network > implement shouldn’t be triggered in this case. > Deployed VM, network gets implemented, stopped/started VR. Repeated this for > VPC as well. > b. VR start via API when network is Allocated state. It should trigger > network implement process. This test case is a good one to test the > chicken-egg problem – VR triggers network implement, and network implement in > turn triggers the provider implementation – which is the virtual router > itself. > Deployed VM, network gets implemented, destroyed VM, after sometime VR gets > stopped and network goes to allocated state. At this point started the VR. > Also repeated same for VPC. > > 4. Ran #3 using XS setup as well > > > Thanks, > > Koushik Das > >
