Thanks Alex, clear now. Cheers, Jay
2013/6/2 Alex Glikson <glik...@il.ibm.com> > One of the goals was to separate between instance placement calculation > logic and the orchestration logic, having each in a separate runtime (see > *https://blueprints.launchpad.net/nova/+spec/query-scheduler*<https://blueprints.launchpad.net/nova/+spec/query-scheduler> > ). Scheduler and conductor (respectively) seemed like a reasonable choice. > > Regards, > Alex > > > > > From: Lau Jay <jay.lau....@gmail.com> > To: Michael Still <mi...@stillhq.com>, > Cc: OpenStack general mailing list <openstack@lists.launchpad.net> > Date: 01/06/2013 06:19 PM > Subject: Re: [Openstack] Benefits for moving live > migration/resize/code migration/provision to conductor > Sent by: "Openstack" <openstack-bounces+glikson= > il.ibm....@lists.launchpad.net> > ------------------------------ > > > > Hi Michael and other Stackers, > > Sorry one more question, for provision VM instance, there is no > interaction between compute nodes, why also move provision logic to > conductor? > > Thanks, > Jay > > > 2013/6/1 Lau Jay <*jay.lau....@gmail.com* <jay.lau....@gmail.com>> > Thanks Michael for the answer, just want to dig more. > > From your answer, it seems that we do not want libvirt on one node opens > up a connection to the other, but from the Gerrit code diff, I did not > notice any change on nova compute, but only move the logic of live > migraiton/resize/code migration from scheduler to conductor, and conductor > still call nova compute directly and once the request cast to nova compute, > libvirt on one node still opens up a connection to the another, so what is > the difference? > > Thanks, > Jay > > > > 2013/6/1 Michael Still <*mi...@stillhq.com* <mi...@stillhq.com>> > IIRC the discussion from the summit, there was concern about compute > nodes talking directly to each other. The way live migration works in > libvirt is that the libvirt on one node opens up a connection to the > other and then streams the instance across. If this is bounced off a > conductor, then it makes firewall rules much easier to construct. > > Cheers, > Michael > > On Sat, Jun 1, 2013 at 2:53 PM, Lau Jay > <*jay.lau....@gmail.com*<jay.lau....@gmail.com>> > wrote: > > Hi Stackers, > > > > I noticed that there are some blueprints trying to move the logic of live > > migration/resize/code migration/provision from nova scheduler to nova > > conductor, but the blueprint did not describe clearly the benefits of > doing > > so, can some experts give some explanation on this? > > > > I know the original design for nova conductor is for a non-db nova > compute, > > but what's the reason of moving scheduling logic to nova conductor? > > > > Thanks, > > > > Jay > > > > _______________________________________________ > > Mailing list: > > *https://launchpad.net/~openstack*<https://launchpad.net/~openstack> > > Post to : *openstack@lists.launchpad.net*<openstack@lists.launchpad.net> > > Unsubscribe : > > *https://launchpad.net/~openstack*<https://launchpad.net/~openstack> > > More help : > > *https://help.launchpad.net/ListHelp*<https://help.launchpad.net/ListHelp> > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
