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 <ravi...@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 < > b22...@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@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Ravi > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
