Open Stack

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.513 at gmail.com>
To:     Michael Still <mikal at stillhq.com>, 
Cc:     OpenStack general mailing list <openstack at 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.com at 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.513 at 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 <mikal at 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.513 at 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 at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130601/4583808e/attachment.html>