Open Stack

I would like to add more context to the mail so everybody is brought up to
speed before we get into more details on tomorrow's meeting.

So the main topic is what we do with the API 'migration-start', which is
currently either a 1-phase migration (migrates and completes) or 2-phase
(migrates up to before being disruptive, and administrator invokes API
'migration-complete')

Briefly addressing a specific detail in Ben's email, there is currently no
polling in the code to perform start+complete in 1 shot.

The 'complete' parameter is what indicates if migration is 1-phase or
2-phase. True indicates it is 1-phase, False indicates it is 2-phase.

For all variations *(A)*, *(B)* and *(C) *below, if 'complete' is False,
then the User has to invoke migration-complete to finish migration, thus
invoking the driver's migration-complete. In *(D)* is as 'complete' is
always False.

*A) What we have today*

User invokes migration_start(complete)
__Manager invokes driver's migration_start(complete)
____Driver holds the request thread to perform migration, polling the
backend until the 1st phase is completed, or all migration is completed,
depending on 'complete' parameter value.
__Manager sets the corresponding status: 'driver_phase1_done' or
'migration_success' depending on 'complete' parameter value.


*B) Driver interface improvement*

We decided that it was not good to have a driver method behavior variation
based on the parameter, and change it to:

User invokes migration_start(complete)
__Manager invokes driver's migration_start()
____Driver holds the request thread to perform migration, polling the
backend until the 1st phase is completed.
__Manager invokes driver's migration_complete or sets status to
'driver_phase1_done' depending on 'complete' parameter value.

*C) Async driver interface with Manager polling, possibly better recovery*

There is this concern that if the service is restarted during a migration,
it may be hard to continue migration from where it left off. So this new
idea came up:

User invokes migration_start(complete)
__Manager invokes driver's migration_start()
____Driver invokes migration in storage and ends.
__Manager stays in a loop invoking driver's migration_continue until it
returns progress = 100%
____Driver performs next vendor specific steps to migrate share and return
progress.
__Manager invokes driver's migration_complete or sets status to
'driver_phase1_done' depending on 'complete' parameter value.

*D) No 1-phase migration, always manually 2-phase*

Additionally, we discussed about removing the possibility of choosing
between 2-phase at all. If the user wants to immediately complete migration
while leaving the share migrating overnight, then he can run a script
outside of manila to monitor the status and trigger migration-complete.
This just simplifies the last Manager step in *(B)* or *(C)* to always set
the status to 'driver_phase1_done'.



Regards,

On Tue, Aug 2, 2016 at 2:03 PM, Ben Swartzlander <ben at swartzlander.org>
wrote:

> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Rodrigo Barbieri
Computer Scientist
OpenStack Manila Core Contributor
Federal University of São Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160803/4cd817d9/attachment.html>