<tt><font size=2>Sandy Walsh <sandy.walsh@rackspace.com> wrote on
31/01/2013 06:35:50 PM:<br>
> >> On Jan 28, 2013, at 12:58 PM, Alex Glikson <GLIKSON@il.ibm.com<br>
> >> [...]<br>
> >>> During the review, an interesting perspective has been
brought up,<br>
> >>> suggesting that such an orchestration is better to be
implemented in<br>
> >>> the recently introduced nova-conductor, rather than in
scheduler.<br>
> >>> While I personally agree that scheduler might not be
the best place<br>
> >>> for orchestration, I wonder whether nova-conductor is
the right<br>
> >>> place, whether people think that it is mature enough
to start<br>
> >>> becoming an orchestration component, and what would make
most sense<br>
> >>> in the short term, to enable a more flexible host evacuation
(in<br>
> >>> Grizzly, hopefully). I am aware of many use-cases where
such<br>
> >>> capability would be of great value.<br>
> >>><br>
> >>> </font></tt><a href=https://review.openstack.org/#/c/19636/><tt><font size=2>https://review.openstack.org/#/c/19636/</font></tt></a><tt><font size=2><br>
> >><br>
> > On Jan 28, 2013, at 3:54 PM, Vishvananda Ishaya <vishvananda@gmail.com<br>
> >> I agree that it might not be the right long-term place for<br>
> >> functionality like this but we haven't yet added any top-down
calls to<br>
> >> the conductor (everything is from the compute-node up), and
until we<br>
> >> move live-migration logic into the conductor I don't see
any reason to<br>
> >> put this functionality there. This seems closely tied with
the<br>
> >> migration code and I think both should be in the same place
wherever<br>
> >> they end up.<br>
> > <br>
> On 01/31/2013 11:34 AM, Chris Behrens wrote:<br>
> > I don't think that "we haven't yet added any top-down calls
to the<br>
> > conductor" is a good reason not to look at it for this.
:)   I'd prefer<br>
> > to see us start moving in the correct direction here.  Fair
point about<br>
> > being close to the live migration code… although I don't know
how close<br>
> > it really needs to be.  If this is just going to fire off
a bunch of<br>
> > live migrations for instances, I don't think it needs to be near.
 If<br>
> > it's going to be more involved, I can see it making sense to
put it near<br>
> > by.  However, I'd rather not see a bunch of orchestration
logic added to<br>
> > the scheduler.  I'd work on things in a different order
and start moving<br>
> > things to nova-conductor where I feel like they now belong.<br>
> <br>
> +1, the scheduler should stay relatively stupid.<br>
> <br>
> (now, whether the conductor is the right place is another debate ...<br>
> though it's likely the best place right now :)</font></tt>
<br>
<br><tt><font size=2>This sounds like a good topic for the upcoming design
summit -- where</font></tt>
<br><tt><font size=2>orchestration should happen? By the way, the question
is relevant not</font></tt>
<br><tt><font size=2>only for Nova.</font></tt>
<br><tt><font size=2>Meanwhile, since most of the orchestration code is
currently in scheduler,</font></tt>
<br><tt><font size=2>and it seems that there is no agreement or design
in place for an </font></tt>
<br><tt><font size=2>alternative, it sounds like a reasonable approach
to implement this (for </font></tt>
<br><tt><font size=2>libvirt/KVM) in the scheduler too.</font></tt>
<br><tt><font size=2>Or would it be a better approach to implement the
orchestration in </font></tt>
<br><tt><font size=2>nova-compute, like it is done today for Xen? </font></tt>
<br>
<br><tt><font size=2>Regards,</font></tt>
<br><tt><font size=2>Alex</font></tt>
<br>
<br>