Open Stack

Thanks.  That link was helpful.

So, I take it that Neutron is a shared service across cells.  Since it is a shared services,  I guess virtual networks based on VXLAN,  VLAN,  GRE technologies can be realized across compute nodes.


Thanks
Srini


From: Qiu Yu [mailto:unicell at gmail.com]
Sent: Friday, August 30, 2013 9:10 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Cells - Neutron Service

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<mailto: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<mailto: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



Cells

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<mailto: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<mailto: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/93f6e918/attachment.html>