Re: [Openstack] Benefits for moving live migration/resize/code migration/provision to conductor
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
Re: [Openstack] Benefits for moving live migration/resize/code migration/provision to conductor
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 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 : 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
Re: [Openstack] Benefits for moving live migration/resize/code migration/provision to conductor
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 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 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 : 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
Re: [Openstack] Benefits for moving live migration/resize/code migration/provision to conductor
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 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 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 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 : 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
Re: [Openstack] Benefits for moving live migration/resize/code migration/provision to conductor
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). 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 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 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 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 : 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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
