Open Stack

Great. I'll try to review as soon as possible since these will be big
changes.
On Sep 17, 2015 12:44 PM, "Carl Baldwin" <carl at ecbaldwin.net> wrote:

> On Thu, Sep 17, 2015 at 10:26 AM, Kevin Benton <blak111 at gmail.com> wrote:
> > Yes, the L2 semantics apply to the external network as well (at least
> with
> > ML2).
>
> This is true and should remain so.  I think we've come to the
> agreement that a neutron Network, external, shared, or not, should be
> an L2 broadcast domain and have these semantics uniformly.
>
> > One example of the special casing is the external_network_bridge option
> in
> > the L3 agent. That would cause the agent to plug directly into a bridge
> so
> > none of the normal L2 agent wiring would occur. With the L2
> bridge_mappings
> > option there is no reason for this to exist anymore because it ignoring
> > network attributes makes debugging a nightmare.
>
> +1
>
> >>Yes, that makes sense.  Clearly the core semantic there is IP.  I can
> > imagine reasonable variation on less core details, e.g. L2 broadcast vs.
> > NBMA.  Perhaps it would be acceptable, if use cases need it, for such
> > details to be described by flags on the external network object.
> >
> > An external network object is just a regular network object with a
> > router:external flag set to true. Any changes to it would have to make
> sense
> > in the context of all networks. That's why I want to make sure that
> whatever
> > we come up with makes sense in all contexts and isn't just a bolt on
> corner
> > case.
>
> I have been working on a proposal around adding better L3 modeling to
> Neutron.  I will have something up by the end of this week.  As a
> preview, my current thinking is that we should add a new object to
> represent an L3 domain.  I will propose that floating ips move to
> reference this object instead of a network.  I'm also thinking that a
> router's external gateway will reference an instance of this new
> object instead of a Network object.  To cover current use cases, a
> Network would own one of these new instances to define the subnets
> that live on the network.  I think we'll also have the flexibility to
> create an L3 only domain or one that spans a group of L2 networks like
> what is being requested by operators [1].
>
> We can also discuss in the context of this proposal how a Port may be
> able to associate with L3-only.  As you know, ports need to provide
> certain L2 services to VMs in order for them to operate.  But, does
> this mean they need to associate to a neutron Network directly?  I
> don't know yet but I tend to think that the model could support this
> as long as VM ports have a driver like Calico behind them to support
> the VMs' dependence on DHCP and ARP.
>
> This is all going to take a fair amount of work.  I'm hoping a good
> chunk of it will fit in the Mitaka cycle.
>
> Carl
>
> [1] https://bugs.launchpad.net/neutron/+bug/1458890
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150922/30ecfb9e/attachment.html>