Open Stack

On 07/28/2015 09:50 PM, Ryan Moats wrote:
> If that's the case, then I'd say let's just solve this right way and
> create a new construct rather...
>
> Ryan Moats
>
> Kevin Benton <blak111 at gmail.com> wrote on 07/28/2015 06:44:53 PM:
>
>  > From: Kevin Benton <blak111 at gmail.com>
>  > To: "OpenStack Development Mailing List (not for usage questions)"
>  > <openstack-dev at lists.openstack.org>
>  > Date: 07/28/2015 06:46 PM
>  > Subject: Re: [openstack-dev] [Neutron][L3] Representing a networks
>  > connected by routers
>  >
>  > We need to work on that code quite a bit anyway for other features
>  > (get me a network, VLAN trunk ports) so adding a different parameter
>  > shouldn't be bad. Even if Nova doesn't initially buy in, we can
>  > always pre-create the port and pass it to Nova boot as a UUID.
>  >
>  > On Tue, Jul 28, 2015 at 6:15 AM, Ryan Moats <rmoats at us.ibm.com> wrote:
>  > Kevin, doesn't this in itself create technical debt on the nova side
>  > in the sense of what an instance attaches to?
>  > I agree that it looks like less technical debt than conditionally
>  > redefining a network, but without nova buy-in, it looks
>  > like a non-starter...
>  >
>  > Ryan
>  >
>  > Kevin Benton <blak111 at gmail.com> wrote on 07/28/2015 02:15:13 AM:
>  >
>  > [snip]
>  >
>  > > I would rather see something to reference a group of subnets that
>  > > can be used for floating IP allocation and port creation in lieu of
>  > > a network ID than the technical debt that conditionally redefining a
>  > > network will bring.

After reading through this thread, I have to agree with Kevin here. A 
new construct for an L3 network seems like a much better long-term 
solution, even if that means a little extra coordination work between 
Nova and Neutron.

The things that Kevin listed that would need conditional logic in 
Neutron is a good indication in my mind that adding a new construct 
(versus modifying the existing L2 network construct in Neutron) is the 
better plan.

Best,
-jay