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" <c...@ecbaldwin.net> wrote:
> On Thu, Sep 17, 2015 at 10:26 AM, Kevin Benton <blak...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ 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
