Open Stack

Hello everyone,

On the yesterday's live migration meeting we had concerns that interval of
writing migration progress to the database is too short.

Information about migration progress will be stored in the database and
exposed through the API (/servers/<uuid>/migrations/<id>). In current
proposition [1] migration progress will be updated every 2 seconds. It
basically means that every 2 seconds a call through RPC will go from compute
to conductor to write migration data to the database. In case of parallel
live migrations each migration will report progress by itself.

Isn't 2 seconds interval too short for updates if the information is exposed
through the API and it requires RPC and DB call to actually save it in the
DB?

Our default configuration allows only for 1 concurrent live migration [2],
but it might vary between different deployments and use cases as it is
configurable. Someone might want to trigger 10 (or even more) parallel live
migrations and each might take even a day to finish in case of block
migration. Also if deployment is big enough rabbitmq might be fully-loaded.
I'm not sure whether updating each migration every 2 seconds makes sense in
this case. On the other hand it might be hard to observe fast enough that
migration is stuck if we increase this interval...

What's worth mentioning is that during Nova Midcycle we had discussion about
refactoring live migration flow. Proposition was to get rid of
compute->compute communication during live migration and make conductor
conduct whole process. Nikola proposed that in such case nova-compute should
be stateful and store migration status on compute node [3]. We might be able
to use state stored on compute node and get rid of RPC-DB queries every 2
seconds.

Thoughts?

Kind Regards,
Pawel Koniszewski

[1] https://review.openstack.org/#/c/258813
[2]
http://docs.openstack.org/liberty/config-reference/content/list-of-compute-c
onfig-options.html
[3] https://etherpad.openstack.org/p/mitaka-nova-midcycle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6499 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160203/10197c17/attachment.bin>