Re: [openstack-dev] [nova][neutron] When are subnets needed on a network to create ports?

[Armando M.]

On 8 November 2016 at 18:35, Matt Riedemann 
wrote:

> I've been looking at this nova bug:
>
> https://bugs.launchpad.net/nova/+bug/1637118
>
> And the neutronv2 API code in nova and need some help from the neutron
> team on how this should actually work.
>

If I am not mistaken [1] is what we'd need on the nova side.

As for neutron, we implemented [2], which can be leveraged by [1] in order
to implement the non-backward compatible behavior of lifting the constraint
check should a port be required without an address.

Mind you, I said port intentionally, meaning that even with [1], bug
1637118 would still manifest itself (in other words, it would be the
expected behavior). Booting off unaddressed VMs is an advanced use case and
as such it requires to boot by specifying the port ID.

[1] https://blueprints.launchpad.net/neutron/+spec/vm-without-l3-address
[2] https://blueprints.launchpad.net/nova/+spec/vm-boot-with-
unaddressed-port



> The validation code that runs from nova-api when creating a server checks
> the requested/available networks to see if they have subnets and if not
> it's a failure. The original change that added that way back in icehouse
> was because you'd get a security group could not be applied failure when
> trying to create ports on a network with port security enabled but that
> didn't have subnets.
>
> Now the code in nova that creates the port, which happens in nova-compute,
> handles this - it only fails if the network doesn't have subnets if the
> network has port security enabled. If the network doesn't have port
> security enabled, we don't care about subnets before creating the port.
>
> However, that icehouse-era validation code that happens in the API side
> before casting to the compute is still there, and that's what the bug is
> saying is a problem.
>
> So that sounds like a legitimate issue, but I wanted to get confirmation
> from the neutron team first before moving forward with a fix.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> 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

[openstack-dev] [nova][neutron] When are subnets needed on a network to create ports?

[Matt Riedemann]

I've been looking at this nova bug:

https://bugs.launchpad.net/nova/+bug/1637118

And the neutronv2 API code in nova and need some help from the neutron 
team on how this should actually work.


The validation code that runs from nova-api when creating a server 
checks the requested/available networks to see if they have subnets and 
if not it's a failure. The original change that added that way back in 
icehouse was because you'd get a security group could not be applied 
failure when trying to create ports on a network with port security 
enabled but that didn't have subnets.


Now the code in nova that creates the port, which happens in 
nova-compute, handles this - it only fails if the network doesn't have 
subnets if the network has port security enabled. If the network doesn't 
have port security enabled, we don't care about subnets before creating 
the port.


However, that icehouse-era validation code that happens in the API side 
before casting to the compute is still there, and that's what the bug is 
saying is a problem.


So that sounds like a legitimate issue, but I wanted to get confirmation 
from the neutron team first before moving forward with a fix.


--

Thanks,

Matt Riedemann


__
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