Open Stack

I found this launchpad discussion, in which Aaron mentioned about network
awareness integration with nova cells.

https://answers.launchpad.net/neutron/+question/228815

Could anyone share some pointers in that direction? Thanks!

Best Regards,
--
Qiu Yu


On Fri, Aug 30, 2013 at 6:40 AM, Ravi Chunduru <ravivsn at gmail.com> wrote:

> Its an interesting discussion you brought up today. I agree there is no
> clear definition of neutron service in that table. The cell goes by its
> definition of ability to create instance anywhere. Then there needs to be
> inter-vm communication for a given network.
>
> I feel Neutron must be shared service in Cells. Such depth is missing in
> Neutron today.
>
> Any thoughts?
>
> Thanks,
> -Ravi.
>
>
> On Thu, Aug 29, 2013 at 8:00 AM, Addepalli Srini-B22160 <
> B22160 at freescale.com> wrote:
>
>>  Hi,****
>>
>> ** **
>>
>> While developing some  neutron extensions, one question came up on Cells.
>> Appreciate any comments.****
>>
>> ** **
>>
>> According to this table in operations guide,  a cell shares nova-api and
>> keystone, but does not talk about other services.****
>>
>> ** **
>>
>> I understand from few that Neutron service need to be shared across cells
>> if virtual networks are to be extended to multiple cells.   Otherwise,
>> neutron service can be dedicated to each cell.****
>>
>> ** **
>>
>> I guess anybody developing  neutron related extensions need to take care
>> both scenarios.****
>>
>> ** **
>>
>> Is that understanding correct?  ****
>>
>> ** **
>>
>> Also which deployments are more common – Shared Neutron or dedicated
>> neutrons?****
>>
>> ** **
>>
>> Thanks
>> Srini****
>>
>> ** **
>>
>> ** **
>>
>> *Cell**s*
>>
>> *Regions*
>>
>> *Availability Zones*
>>
>> *Host Aggregates*
>>
>> *Use when you need* ****
>>
>> A single API endpoint<http://docs.openstack.org/trunk/openstack-ops/content/scaling.html>for compute, or you require a second level of scheduling.
>> ****
>>
>> Discrete regions with separate API endpoints and no coordination between
>> regions.****
>>
>> Logical separation within your nova deployment for physical isolation or
>> redundancy.****
>>
>> To schedule a group of hosts with common features.****
>>
>> *Example* ****
>>
>> A cloud with multiple sites where you can schedule VMs "anywhere" or on a
>> particular site.****
>>
>> A cloud with multiple sites, where you schedule VMs to a particular site
>> and you want a shared infrastructure.****
>>
>> A single site cloud with equipment fed by separate power supplies.****
>>
>> Scheduling to hosts with trusted hardware support.****
>>
>> *Overhead* ****
>>
>> **·         **A new service, nova-cells****
>>
>> **·         **Each cell has a full nova installation except nova-api****
>>
>> **·         **A different API endpoint for every region. ****
>>
>> **·         **Each region has a full nova installation.****
>>
>> **·         **Configuration changes to nova.conf****
>>
>> **·         **Configuration changes to nova.conf****
>>
>> *Shared services* ****
>>
>> Keystone****
>>
>> nova-api ****
>>
>> Keystone****
>>
>> Keystone****
>>
>> All nova services****
>>
>> Keystone****
>>
>> All nova services****
>>
>> ** **
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Ravi
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130831/4277aeab/attachment.html>