Open Stack

Sandy Walsh <sandy.walsh at rackspace.com> wrote on 31/01/2013 06:35:50 PM:
> >> On Jan 28, 2013, at 12:58 PM, Alex Glikson <GLIKSON at il.ibm.com
> >> [...]
> >>> 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/
> >>
> > On Jan 28, 2013, at 3:54 PM, Vishvananda Ishaya <vishvananda at gmail.com
> >> 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.
> > 
> On 01/31/2013 11:34 AM, Chris Behrens wrote:
> > 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 :)

This sounds like a good topic for the upcoming design summit -- where
orchestration should happen? By the way, the question is relevant not
only for Nova.
Meanwhile, since most of the orchestration code is currently in scheduler,
and it seems that there is no agreement or design in place for an 
alternative, it sounds like a reasonable approach to implement this (for 
libvirt/KVM) in the scheduler too.
Or would it be a better approach to implement the orchestration in 
nova-compute, like it is done today for Xen? 

Regards,
Alex

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