[openstack-dev] [neutron][heat] - making Neutron more friendly for orchestration
armamig at gmail.com
Fri May 19 22:27:21 UTC 2017
On 19 May 2017 at 14:54, Clark Boylan <cboylan at sapwetik.org> wrote:
> On Fri, May 19, 2017, at 02:03 PM, Kevin Benton wrote:
> > I split this conversation off of the "Is the pendulum swinging on PaaS
> > layers?" thread  to discuss some improvements we can make to Neutron
> > to
> > make orchestration easier.
> > There are some pain points that heat has when working with the Neutron
> > API.
> > I would like to get them converted into requests for enhancements in
> > Neutron so the wider community is aware of them.
> > Starting with the port/subnet/network relationship - it's important to
> > understand that IP addresses are not required on a port.
> > >So knowing now that a Network is a layer-2 network segment and a Subnet
> > is... effectively a glorified DHCP address pool
> > Yes, a Subnet controls IP address allocation as well as setting up
> > routing
> > for routers, which is why routers reference subnets instead of networks
> > (different routers can route for different subnets on the same network).
> > It
> > essentially dictates things related to L3 addressing and provides
> > information for L3 reachability.
> One thing that is odd about this is when creating a router you specify
> the gateway information using a network which is l2 not l3. Seems like
> it would be more correct to use a subnet rather than a network there?
I think this is due the way external networks ended up being modeled in
neutron. I suppose we could have allowed the user to specify a subnet, so
long that it fell in the bucket of subnets that belong to a router:external
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev