Open Stack

On 8 November 2016 at 18:35, Matt Riedemann <mriedem at linux.vnet.ibm.com>
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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161108/db28142d/attachment.html>