
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 28, 2013, at 12:58 PM, Alex Glikson <<a href="mailto:GLIKSON@il.ibm.com">GLIKSON@il.ibm.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><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> </blockquote><br></div><div>I agree that it might not be the right long-term place for functionality like this but we haven't yet added any top-down calls to the conductor (everything is from the compute-node up), and until we move live-migration logic into the conductor I don't see any reason to put this functionality there. This seems closely tied with the migration code and I think both should be in the same place wherever they end up.</div><div><br></div><div>Vish</div></body></html>