Re: [openstack-dev] [neutron][heat] - making Neutron more friendly for orchestration

2017-05-23 Thread Kevin Benton
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'

Re: [openstack-dev] [neutron][heat] - making Neutron more friendly for orchestration

2017-05-23 Thread Zane Bitter
On 19/05/17 19:53, Kevin Benton wrote: So making a subnet ID mandatory for a port creation and a RouterInterface ID mandatory for a Floating IP creation are both possible in Heat without Neutron changes. Presumably you haven't done that because it's backwards-incompatible, but you would need to

Re: [openstack-dev] [neutron][heat] - making Neutron more friendly for orchestration

2017-05-19 Thread Kevin Benton
So making a subnet ID mandatory for a port creation and a RouterInterface ID mandatory for a Floating IP creation are both possible in Heat without Neutron changes. Presumably you haven't done that because it's backwards-incompatible, but you would need to implement the change anyway if the

Re: [openstack-dev] [neutron][heat] - making Neutron more friendly for orchestration

2017-05-19 Thread Zane Bitter
On 19/05/17 17:03, Kevin Benton wrote: I split this conversation off of the "Is the pendulum swinging on PaaS layers?" thread [1] 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

Re: [openstack-dev] [neutron][heat] - making Neutron more friendly for orchestration

2017-05-19 Thread Armando M.
On 19 May 2017 at 14:54, Clark Boylan 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 [1] to discuss some improvements we can make to Neutron > > to > > make

Re: [openstack-dev] [neutron][heat] - making Neutron more friendly for orchestration

2017-05-19 Thread Clark Boylan
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 [1] to discuss some improvements we can make to Neutron > to > make orchestration easier. > > There are some pain points that heat has when working

Re: [openstack-dev] [neutron][heat] - making Neutron more friendly for orchestration

2017-05-19 Thread Kevin Benton
We could potentially alter Neutron to inspect each of the fixed IPs to see if it's eligible to be associated to that floating IP to find the one that works. Unfortunately that still won't solve multiple eligible fixed IPs. So is the right thing to do to just always force the user to specify

Re: [openstack-dev] [neutron][heat] - making Neutron more friendly for orchestration

2017-05-19 Thread Monty Taylor
On 05/19/2017 04:03 PM, Kevin Benton wrote: I split this conversation off of the "Is the pendulum swinging on PaaS layers?" thread [1] 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

[openstack-dev] [neutron][heat] - making Neutron more friendly for orchestration

2017-05-19 Thread Kevin Benton
I split this conversation off of the "Is the pendulum swinging on PaaS layers?" thread [1] 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