Open Stack

On 01/31/2013 11:34 AM, Chris Behrens wrote:
> 
> On Jan 28, 2013, at 3:54 PM, Vishvananda Ishaya <vishvananda at gmail.com
> <mailto:vishvananda at gmail.com>> wrote:
> 
>>
>> On Jan 28, 2013, at 12:58 PM, Alex Glikson <GLIKSON at il.ibm.com
>> <mailto: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.

+1, the scheduler should stay relatively stupid.

(now, whether the conductor is the right place is another debate ...
though it's likely the best place right now :)

-S


> - Chris
> 
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>