Deepti B Kalakeri wrote:
Kaitlin Rupert wrote:
This set looks good! I haven't had a chance to test on Xen yet. Also, if you are planning to include all of the migration types in one test, you'll want to change the test name from 06_remote_live_migration.py to something more generic.
I would prefer to have different test cases for different types, otherwise tracking the issues would be more problematic, the test case will be lengthier and complex keeping the scenarios separate gives a ready to use tc for verifying regression for different migration types if any.
Thoughts ??
These are good arguments. I'm fine with either approach. The single test approach means there is less code duplication across multiple tests (because each test will basically be the same, right?). So it's less of a maintenance headache if things change later on.
Since most of the code in the test cases is to do with guest defining/starting/destroying and then passing appropriate migration info I think these would not change much. Also, for the new tests I will see if I can include more scenarios in the same test case.
This is fine by me =) -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com