openstack team mailing list archive

[Lau Jay <jay.lau.513@xxxxxxxxx>]

Thanks Alex, clear now.

Cheers,
Jay


2013/6/2 Alex Glikson <GLIKSON@xxxxxxxxxx>

> 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.513@xxxxxxxxx>
> To:        Michael Still <mikal@xxxxxxxxxxx>,
> Cc:        OpenStack general mailing list <openstack@xxxxxxxxxxxxxxxxxxx>
> 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@xxxxxxxxxxxxxxxxxxx>
> ------------------------------
>
>
>
> 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@xxxxxxxxx* <jay.lau.513@xxxxxxxxx>>
> 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@xxxxxxxxxxx* <mikal@xxxxxxxxxxx>>
> 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@xxxxxxxxx*<jay.lau.513@xxxxxxxxx>>
> 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@xxxxxxxxxxxxxxxxxxx*<openstack@xxxxxxxxxxxxxxxxxxx>
> > 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>