Thanks Alex, clear now. Cheers, Jay
2013/6/2 Alex Glikson <[email protected]> > 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 <[email protected]> > To: Michael Still <[email protected]>, > Cc: OpenStack general mailing list <[email protected]> > 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= > [email protected]> > ------------------------------ > > > > 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 <*[email protected]* <[email protected]>> > 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 <*[email protected]* <[email protected]>> > 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 > <*[email protected]*<[email protected]>> > 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 : *[email protected]*<[email protected]> > > 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 : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
