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
smime.p7s
Description: S/MIME cryptographic signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
