On 25 February 2016 at 10:01, Tim Bell <tim.b...@cern.ch> wrote: > > CERN info added.. Feel free to come back for more information if needed. > > Tim > On 24/02/16 22:47, "Edgar Magana" <edgar.mag...@workday.com> wrote: > >>It will be awesome if we can add this doc into the networking guide :-) >> >> >>Edgar >> >>On 2/24/16, 1:42 PM, "Matt Riedemann" <mrie...@linux.vnet.ibm.com> wrote: >> >>>The nova and neutron teams are trying to sort out existing deployment >>>network scenarios for cells v1 so we can try and document some of that >>>and get an idea if things change at all with cells v2. >>> >>>Therefore we're asking that deployers running cells please document >>>anything you can in an etherpad [1]. >>> >>>We'll try to distill that for upstream docs at some point and then use >>>it as a reference when talking about cells v2 + networking. >>> >>>[1] https://etherpad.openstack.org/p/cells-networking-use-cases
I certainly looks like most of the deployments have evolved from a nova-network deploy in each child cell. On the Rackspace side, I think carl baldwin's current plans should allow our neutron and cells to sit together nicely: * https://review.openstack.org/#/c/225384/ and https://review.openstack.org/#/c/263898/ Attempt at a quick summary: * networks can be split into L2 segments, each segment with its own set of IP subnets * port IP assignment delayed until it hits a specific L2 segment * scheduling on the nova side that is IP capacity aware for unassigned ports * re-used ports would keep their IP, so they must be attached in the correct L2 segment (via boot or otherwise) * new solution will not be fixed on cell boundaries It would be great to get more feedback on the above approach, to see if that meets your specific needs. Thanks, johnthetubaguy _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
