<font size=2 face="sans-serif">Hi all,</font>
<br>
<br><font size=2 face="sans-serif">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. </font>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><a href=https://review.openstack.org/#/c/19636/><font size=2 face="sans-serif">https://review.openstack.org/#/c/19636/</font></a>
<br>
<br><font size=2 face="sans-serif">Would appreciate your thoughts.</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br><font size=2 face="sans-serif">Alex Glikson</font>
<br><font size=2 face="sans-serif">IBM Research</font>
<br>