Open Stack

Hi all,

As (some of) you know, a host can be put into maintenance mode by invoking 
"host_update <host-xx> ?maintenance enable/disable", which would disable 
future provisioning on this host, and would trigger migration of guest VMs 
to other hosts (e.g., within a host aggregate). Such requests are 
currently routed directly to the nova-compute on the corresponding node. 
The only implementation is available for Xen, delegating to XenAPI pool 
operations. 
We have recently submitted a small patch directing the host maintenance 
requests to scheduler instead of nova-compute, aiming to enable wider 
range of implementations. A rather straightforward implementation that we 
had in mind could leverage the scheduler capabilities to find placement 
for VMs, and live migration capabilities to evacuate them.
During the review, an interesting perspective has been brought up, 
suggesting that such an orchestration is better to be implemented in the 
recently introduced nova-conductor, rather than in scheduler.
While I personally agree that scheduler might not be the best place for 
orchestration, I wonder whether nova-conductor is the right place, whether 
people think that it is mature enough to start becoming an orchestration 
component, and what would make most sense in the short term, to enable a 
more flexible host evacuation (in Grizzly, hopefully). I am aware of many 
use-cases where such capability would be of great value.

https://review.openstack.org/#/c/19636/

Would appreciate your thoughts.

Thanks,
Alex Glikson
IBM Research
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130128/0420abe4/attachment.html>