Open Stack

On Jan 28, 2013, at 3:54 PM, Vishvananda Ishaya <vishvananda at gmail.com> wrote:

> 
> On Jan 28, 2013, at 12:58 PM, Alex Glikson <GLIKSON at il.ibm.com> wrote:
> 
>> 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. 
> 
> 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.

I don't think that "we haven't yet added any top-down calls to the conductor" is a good reason not to look at it for this. :)   I'd prefer to see us start moving in the correct direction here.  Fair point about being close to the live migration code… although I don't know how close it really needs to be.  If this is just going to fire off a bunch of live migrations for instances, I don't think it needs to be near.  If it's going to be more involved, I can see it making sense to put it near by.  However, I'd rather not see a bunch of orchestration logic added to the scheduler.  I'd work on things in a different order and start moving things to nova-conductor where I feel like they now belong.

- Chris


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130131/5bfc44ec/attachment.html>