On 8 November 2016 at 18:35, Matt Riedemann <[email protected]> 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
