[openstack-dev] [neutron][heat] - making Neutron more friendly for orchestration
kevin at benton.pub
Wed May 24 05:49:50 UTC 2017
We chatted a bit about this on IRC. The issue here is that subnets that
belong to router:external networks are not visible unless the network is
shared as well.
So the only way the users can learn about which subnets to pick are in the
list of subnet UUIDs in the json body of the network 'subnets' field.
They would basically be picking blindly because they don't know any details
about the subnets on the external network.
I think for us to allow a reasonable workflow where they pick an external
subnet instead, we would need to revisit the decision to hide external
subnets from users.
On Fri, May 19, 2017 at 3:27 PM, Armando M. <armamig at gmail.com> wrote:
> 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:unsubscrib
> 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