Open Stack

On 25 February 2016 at 10:01, Tim Bell <Tim.Bell at 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.magana at 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" <mriedem at 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