On Sun, May 1, 2016 at 7:01 PM, Matt Riedemann <mrie...@linux.vnet.ibm.com> wrote: > On Wednesday morning the Nova and Neutron teams got together for a design > summit session. The full etherpad is here [1]. > > We talked through three major items. > > 1. Neutron routed networks. > > Carl Baldwin gave a quick recap that we're on track with the Nova spec [2] > and had pushed a new revision which addressed Dan Smith's latest comments. > The spec is highly dependent on Jay Pipes' generic-resource-pools spec which > needs to be rebated, and then hopefully we can approve that this week and > the routed networks one shortly thereafter. > > We spent some time with Dan Smith sketching out his idea for moving the > neutron network allocation code from the nova compute node to conductor. > This would help with a few things: > > a) Doing the allocation earlier in the process so it's less expensive if we > fail on the compute and get into a retry loop. > > b) It should clean up a bunch of the allocation code that's in the network > API today, so we can separate the allocation logic from the check/update > logic. This would mean that by the time we get to the compute the ports are > already allocated and we just have to check back with Neutron that they are > still correct and update their details. And that would also mean by the time > we get to the compute it looks the same whether the user provided the port > at boot time or Nova allocated it. > > c) Nova can update it's allocation tables before scheduling to make a more > informed decision about where to place the instance based on what Neutron > has already told us is available. > > John Garbutt is planning on working on doing this cleanup/refactor to move > parts of the network allocation code from the compute to conductor. We'll > most likely need a spec for this work.
Matt, This is a good summary from my point of view. I just want to say it was a pleasure to be there. I thought it was very productive for both teams. Carl __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev