<div dir="ltr">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.<div><br></div><div>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')</div><div><br></div><div>Briefly addressing a specific detail in Ben's email, there is currently no polling in the code to perform <span style="font-size:12.8px">start+complete in 1 shot.</span><br></div><div><span style="font-size:12.8px"><br></span></div><div><div>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.</div></div><div><br></div><div><div>For all variations <b>(A)</b>, <b>(B)</b> and <b>(C) </b>below, if 'complete' is False, then the User has to invoke migration-complete to finish migration, thus invoking the driver's migration-complete. In <b>(D)</b> is as 'complete' is always False.</div></div><div><br></div><div><div><b>A) What we have today</b><br></div><div><br></div><div>User invokes migration_start(complete)<br></div><div>__Manager invokes driver's migration_start(complete)</div><div>____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.</div><div>__Manager sets the corresponding status: 'driver_phase1_done' or 'migration_success' depending on 'complete' parameter value.</div><div><br></div><div><br></div><div><b>B) Driver interface improvement</b></div><div><br></div><div>We decided that it was not good to have a driver method behavior variation based on the parameter, and change it to:</div><div><br></div><div><div>User invokes migration_start(complete)<br></div><div>__Manager invokes driver's migration_start()</div><div>____Driver holds the request thread to perform migration, polling the backend until the 1st phase is completed.</div><div>__Manager invokes driver's migration_complete or sets status to 'driver_phase1_done' depending on 'complete' parameter value.</div></div><div><br></div><div><b>C) Async driver interface with Manager polling, possibly better recovery</b></div><div><br></div><div>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:</div><div><br></div><div><div>User invokes migration_start(complete)<br></div><div>__Manager invokes driver's migration_start()</div><div>____Driver invokes migration in storage and ends.</div><div>__Manager stays in a loop invoking driver's migration_continue until it returns progress = 100%</div><div>____Driver performs next vendor specific steps to migrate share and return progress.</div><div>__Manager invokes driver's migration_complete or sets status to 'driver_phase1_done' depending on 'complete' parameter value.</div></div><div><br></div><div><div><b>D) No 1-phase migration, always manually 2-phase</b><br></div></div><div><br></div><div> 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>(B)</b> or <b>(C)</b> to always set the status to 'driver_phase1_done'.</div><div><br></div><div><br></div><div><br></div><div>Regards,</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 2, 2016 at 2:03 PM, Ben Swartzlander <span dir="ltr"><<a href="mailto:ben@swartzlander.org" target="_blank">ben@swartzlander.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
-Ben Swartzlander<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Rodrigo Barbieri<div>Computer Scientist</div><div>OpenStack Manila Core Contributor</div><div>Federal University of São Carlos</div><div><br></div></div></div></div></div></div>
</div>