> On March 19, 2014, 3:32 p.m., Santhosh Edukulla wrote: > > test/integration/component/test_usage.py, line 680 > > <https://reviews.apache.org/r/19399/diff/1/?file=528014#file528014line680> > > > > Also, just a thought. If stop operation itself verifies the state and > > return, so test case can check some thing like if virtual_machine.stop() == > > FAIL: > > raise\fail. I believe we can use getState inside stop operation > > itself. Basically, stop operation return can be enforced and checked. > >
Here if we don't want to touch existing test cases with stop operation, we will have to raise Exception through stop method if getState return FAIL to Stop method. Is that ok? - Ashutosh ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19399/#review37723 ----------------------------------------------------------- On March 19, 2014, 3:10 p.m., Ashutosh Kelkar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/19399/ > ----------------------------------------------------------- > > (Updated March 19, 2014, 3:10 p.m.) > > > Review request for cloudstack and Santhosh Edukulla. > > > Bugs: CLOUDSTACK-6257 > https://issues.apache.org/jira/browse/CLOUDSTACK-6257 > > > Repository: cloudstack-git > > > Description > ------- > > As suggested, added getState method for VirtualMachine class, and it is > called before template creation. If VM fails to go into desired state, it > returns failure. > > > Diffs > ----- > > test/integration/component/test_project_usage.py ba0a63c > test/integration/component/test_resource_limits.py f0d558e > test/integration/component/test_tags.py 2a6e076 > test/integration/component/test_templates.py 3e83615 > test/integration/component/test_usage.py 5979a0a > tools/marvin/marvin/integration/lib/base.py 775b289 > > Diff: https://reviews.apache.org/r/19399/diff/ > > > Testing > ------- > > Yes. > > > Thanks, > > Ashutosh Kelkar > >
