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 <[email protected]> wrote on 07/28/2015 06:44:53 PM:
> From: Kevin Benton <[email protected]>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <[email protected]>
> 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 <[email protected]> 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 <[email protected]> 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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev