Open Stack

Hi,

> There are currently no tests for live migration. I imagine that the reason is
> because there is very poor documentation on the os-migrateLive API
> extension. I'd be happy to help you in writing the tests.
Cool, thanks.

> I'd love some help in identifying some documentation
> ...
> we need to know the
> contractual state changes that need to be asserted in the Tempest tests.
>
> Additionally, I'd like to point out that there is a lot of confusion as to what is
> different between the standard Compute API call to "migrate a server"
> (POST /servers/<SERVER_ID>/action with 'migrate' action...) and the live
> migration extension.
> ...

+1

Renuka and I are looking at proposing a blueprint to try and sort out some of this confusion.

I think this is the current situation:
- historically XenAPI had migrate, Libvirt had live migrate
- But by end of Folsom we should have both having both
- Live migration was originally only nova-manage controlled
- Migrate is useful, but requires things like passwordless ssh
- We could re-implement migrate as snapshot and restart
- Above is also true for Resize
- But there may be billing implications for the above changes
- Live-migrate is more useful than migrate
- But live-migrate not always possible (miss matched CPUs, etc)
- Ideally we would have single migrate/live-migrate API 

Possible first steps for Folsom:
- Extend the migrate API to support a "live" and "live-block" migration options
- Maybe add "live with fallback to non-live" option
- Maybe above should be the default, add a "non-live" option
- Fully document the expanded migrate API for Folsom

Does this sound reasonable?

Cheers,
John