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]> > 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]> > >> 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]> 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 >> > 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
