It occurred to me that if we write the 2-phase migration APIs correctly,
then it will be fairly trivial to implement 1-phase migration outside
Manila (in the client, or even higher up).
I would like to propose that we change the migration API to actually
work that way, because I think it will have positive impact on the
driver interface and it will make the internals for migration a lot
simpler. Specifically, I'm proposing that the Manila REST API only
supports starting/completing migrations, and querying the status of an
ongoing migration -- there should be no automatic looping inside Manila
to perform a start+complete in 1 shot.
Additionally I think it makes sense to make all the migration driver
interfaces more asynchronous, but that change is less urgent. Getting
the driver interface exactly right is less important than getting the
REST API right in Newton. Nevertheless, I think we should aim for a
driver interface that expects all the migration calls to return quickly
and for status polling to occur automatically on long running
operations. This will enable much better behavior when restarting
services during a migration.
I'm going to put a topic on the meeting agenda for Thursday to discuss
this in more detail, but if anyone has other feelings please chime in here.
-Ben Swartzlander
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
