----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24152/#review50853 -----------------------------------------------------------
Ship it! master -> 8bc7ae695d621b67e1e5d1916a1852cad1f4dda0 - Koushik Das 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 > >
