Creating Neutron L2 networks (without subnets) doesn't work as expected

[Ian Wells]

1. create a network in Quantum. Networks no longer need subnets, so I create a network without one. (Imagine I'm doing my addressing some other way.

    quantum net-create test

<returns an ID>

2. create a machine with that network attached via nova.

nova boot --image xxx --flavor yyy --nic net-id=e85d5994-7f8e-4024-bde9-c1cdb2b202d0 hasnet

All good. The machine boots perfectly well. However, it comes up without any NICs.

It turns out that VIF.legacy() is called just before calling driver.spawn() for the virt driver. This converts the VIF datastructure from the network model to its old form (because the virtualisation layer has not been brought up to date with the new model). The old form can't be created without, at least, an IPv4 address - so, in the above example where no address has been assigned to the VIF, it is silently omitted from the legacy version of the datastructure, and no NIC is added to the VM as the network_info datastructure is now empty.

So:

- am I even calling the API correctly? Since nova-manage network create and quantum net-create both work, and no-one's written up the documentation yet, I can't tell that I'm doing this right (although I got no joy out of the IDs that nova-manage was returning)
- is this going to last into Folsom RCs or will it be fixed?
- if it is going to stay with us, perhaps we could throw an error at this point rather than continuing to create the wrong sort of VM?

(I need this functionality so I shall have to find a workaround if it's going to stay missing.)

[Ian Wells (ijw-ubuntu)]

Ah, just found the legacy_nwinfo() call on the hypervisor drivers - so it matters that I'm using libvirt, which hasn't yet been updated.

[Mark McLoughlin (markmc)]

From bug #1039419, it looks like what you're trying to do is expected to work

Thanks for all the info, I think there's plenty here to go on for someone familiar with the quantum integration. Marking as Confirmed and targeting to rc1

[Ian Wells (ijw-ubuntu)]

Thanks for the reference.

I'm working on the patches for libvirt to use the new network model as we speak. (This may not be a complete fix depending on what else uses the legacy models, though.)

[dan wendlandt (danwent)]

Ian, can you assign this bug to yourself? It would be great to see a work-in-progress patch on this soon, so someone from the nova-network team could provide some initial feedback, particularly about the impact of the changes on non-libvirt code.

[Ian Wells (ijw-ubuntu)]

Certainly. I actually have a patch that's working for my purposes, but it fails some white-box libvirt tests where the harness is passing in old-style data structures. I'll try and get it on Gerrit today.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/11923

[Akihiro Motoki (amotoki)]

Ian,

When I tried to access the above gerrit link https://review.openstack.org/11923, I got an error message which says "Application Error The page you requested was not found, or you do not have permission to view this page."

How can I access the review?

[Ian Wells (ijw-ubuntu)]

Sorry, I only put it up as a draft till I fixed a couple of issues, but apparently Gerrit linked it to the bug anyway.
I'll fix a couple of things and I'll put it up in a few hours.

[Ian Wells (ijw-ubuntu)]

Patch only fixes libvirt, but that should be all that's needed:

- You can only have a no-subnets case if you're using Quantum
- Apparently, only libvirt has VIF drivers for Quantum, so I assume it's the only one with Quantum support.

Thus, if the patch is approved, this can be closed (though we probably ought to open bugs against the other drivers for Quantum support...)

[dan wendlandt (danwent)]

xenserver also has vif drivers for quantum: virt/xenapi/vif.py

I haven't looked at this bug in detail, but my guess is that the problem is caused by some vif-drivers assuming they know IP layer information about a VM, which obviously doesn't exist if there is no subnet. If that's the case, I don't think this issue would apply to the xenserver drivers, based on a quick inspection.

[Ian Wells (ijw-ubuntu)]

Ah, possibly my mistake. It's that there's something specifically Quantum in the libvirt and no mention of Quantum in the XenAPI version.

[Akihiro Motoki (amotoki)]

/Information for quantum people using devstack/

To reproduce the bug, we need to use the default libvirt firewall driver (nova.virt.libvirt.firewall.IptablesFirewallDriver).
Please clear LIBVIRT_FIREWALL_DRIVER in localrc.

Note that QuantumDevstack wiki pages recommends "LIBVIRT_FIREWALL_DRIVER=nova.virt.firewall.NoopFirewallDriver") when using devstack with Quantum v2.

[dan wendlandt (danwent)]

Akihiro,

Yes, it is true that our devstack page recommends using the NoopFirewallDriver, but that is only until we merge a patch currently under review that let's Nova security groups work with Quantum, after which point using the IptablesFirewallDriver is supported (see: https://bugs.launchpad.net/quantum/+bug/1039400). So I consider this bug valid.

[Akihiro Motoki (amotoki)]

Thanks for the pointer. I consider this bug is valid too

I understand that using NoopFirewallDriver is transient.
First time I tried to reproduce, I could not due to this configuration, so it is worth sharing the information to test Ian's patch.

Thanks

[dan wendlandt (danwent)]

On Thu, Aug 30, 2012 at 2:26 AM, Akihiro Motoki
<email address hidden> wrote:

> First time I tried to reproduce, I could not due to this configuration, so it is worth sharing the information to test Ian's patch.

definitely agree :) I guess I misunderstood your original comment.

[Ian Wells (ijw-ubuntu)]

Akihiro, can you confirm you created a subnetless network with NoopFirewallDriver and your machine got an interface on it? Because that's exactly the situation I was in when I saw this bug in the first place - I don't believe it's specific to the firewall driver in use.

[Akihiro Motoki (amotoki)]

I investigated the condition this bug can be reproduced. Firewall driver is not related.

When using devstack, to reproduce ths bug, we must remove a subnet which created by devstack.
This is another bug #1043827. If bug #1043827 is resolved, this bug always happens when an instance is launched with a network without subnet.

[Mark McLoughlin (markmc)]

Just for anyone checking the status of this - lots of discussion in https://review.openstack.org/11923

[Ian Wells (ijw-ubuntu)]

I am unconvinced that this can be fixed without also fixing the firewalling, which does not stand up to the unexpected situations Quantum brings (0+ addresses rather than precisely one). I think we should work out a solution that covers on all the issues.

[Ian Wells (ijw-ubuntu)]

I've not been doing Grizzly work, but a colleague points out to me that the code seems to have been converted to use new-style VIF types since Folsom. Does anyone know if this bug still stands in Grizzly?

[Ian Wells (ijw-ubuntu)]

Oops, wrong branch. I take that back. And I'll have a look at this in the next week.

[Vish Ishaya (vishvananda)]

Lowering the priority on this as it doesn't seem to be a very important use case. We should get a free fix in havanna from the code here:

https://review.openstack.org/#/c/21382

[Brent Eagles (beagles)]

The current approach is dependent on port security extensions in neutron. A complete fix requires changes in both components.

[Sean Dague (sdague)]

Is this still a valid bug? If so can we get a new consolidated reproduce case?

[Ian Wells (ijw-ubuntu)]

Been a long while since I tried this and I don't have a suitable cloud handy to test, but if it does exist the following 5 minute test shows it up:

1. create a Neutron network
2. create a VM attached to that network (NB: Cirros has a default password which makes the following steps easier)
.. wait for futile DHCP'ing to pass ..
3. log into the VM on its console

Historical behaviour is that the VM would come up fine but with 0 interfaces. With more interfaces on the VM, you'd end up short the interface(s) on the no-subnet network(s) (and automated testing is feasible since not all networks need be no-subnet). I believe we also went through a phase of 'no valid host' when nova-compute was crashing out, too.

I'm fairly sure this *has* been fixed, though.

[Racha Ben Ali (racha-ben-ali)]

Ian, do you know if there's an NFV config flag or specific release that I should use to get rid of this message when I try it:

ERROR (BadRequest): Network 5ea23e60-a26b-409a-b388-f812177bbf92 requires a subnet in order to boot instances on. (HTTP 400) (Request-ID: req-22141a06-3d0c-480f-9860-5733c759ba9b)

I can create a non immediately working subnet with --disable-dhcp on the no-subnet network, but then iptables filtering will allow traffic only from pre-defined IP/MAC pairs if I don't allow address pairs manually through the API I guess...

[Sean Dague (sdague)]

assuming it's fixed, please reopen if still an issue

[Thiago Martins (martinx)]

From what I'm seeing, with IceHouse / Juno, it is not possible to even start an Instance attached to a Network without a Subnet.

And I really need this feature... :-(

Currently, I'm patching OpenStack to make this work, here is the code for review:

https://review.openstack.org/#/c/59578/

https://review.openstack.org/gitweb?p=openstack%2Fnova.git;a=commitdiff;h=a6c9a67723a92f435e0e8eff9eb43b618c7cf0bb

[Thiago Martins (martinx)]

I just found a nice example of this need (L2 Neutron Networks), right here:

https://nfv.net/2015/02/network-neutron/

Cheers!

[Thiago Martins (martinx)]

I'm reopening (confirming) this, since it is not fixed and Sean allowed that (comment #30).

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/202882

[Markus Zoeller (markus_z) (mzoeller)]

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (LIBERTY, MITAKA, OCATA, NEWTON).
  Valid example: CONFIRMED FOR: LIBERTY

[OpenStack Infra (hudson-openstack)]

Change abandoned by Michael Still (<email address hidden>) on branch: master
Review: https://review.openstack.org/202882
Reason: This code hasn't been updated in a long time, and is in merge conflict. I am going to abandon this review, but feel free to restore it if you're still working on this.

[Joshua Castaneda (senterright)]

Dang I think I need this. :| I'm trying to simulate a failover scenario where i just want to have my backup gateway connected over L2, but without an L3 address until the master goes down.

[Dominic (abhi-02666)]

Is this still a valid bug? If so can we get a new consolidated reproduce case
Info that is meant to be shared across the net.
Shame on the search engines for not positioning this put up higher!
https://www.techsupportdubai.com/led-tv-repair/
these codes are updated these benefits are using for work

[Nick Jones (wavexcoin007)]

Wavex is a US-based Coin that specializes in crypto-enabled financial services. Wavex is all set to bring a revolution with its Coin based products by developing borderless financial services that assure a simpler Best crypto exchange, buy and sell cryptocurrency, uninterrupted and quick flow of capital.
https://wavexcoins.com/

[Car Expert (carexpert007)]

Very quick, cordial and efficient car service at your doorstep from Car Expert. We aim to earn your trust and have a long term relationship with you.
https://www.carexpert.org.in/

[Nick Jones (brainmaptechnology007)]

At Brainmap, we serve as a telecom service provider, helping businesses boost their communication and take it to a new level.
https://brainmaptechnologies.com/