vif-driver of Nova requires Portbindings extension

[Yoshihiro Kaneko]

I used Ryu plugin with Nova LibvirtHybridOVSBridgeDriver.
When I launched an instance, the following problems occurred on nova-compute.

 Traceback (most recent call last):
   File "/opt/stack/nova/nova/compute/manager.py", line 960, in _spawn
     block_device_info)
   File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 1029, in spawn
     block_device_info=block_device_info)
   File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 1808, in to_xml
     rescue, block_device_info)
   File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 1766, in get_guest_config
     self.vif_driver.plug(instance, (network, mapping))
   File "/opt/stack/nova/nova/virt/libvirt/vif.py", line 247, in plug
     instance['uuid'])
   File "/opt/stack/nova/nova/virt/libvirt/vif.py", line 160, in create_ovs_vif_port
     run_as_root=True)
   File "/opt/stack/nova/nova/utils.py", line 232, in execute
     cmd=' '.join(cmd))
 ProcessExecutionError: Unexpected error while running command.
 Command: sudo nova-rootwrap /etc/nova/rootwrap.conf ovs-vsctl -- --may-exist add-port None qvo75dfeac7-01 -- set Interface qvo75dfeac7-01 external-ids:iface-id=75dfeac7-0123-402a-b662-d4edd1327681 external-ids:iface-status=active external-ids:attached-mac=fa:16:3e:eb:d4:1f external-ids:vm-uuid=3b6cdd97-6586-478e-bbc2-73b36a8497e5

It seems the result of Change Ib043e1e6.
  Make Quantum plugin fill in the 'bridge' name
  https://review.openstack.org/#/c/19119/

nova/network/quantumv2/api.py
    bridge = None
    vif_type = port.get('binding:vif_type')
    # TODO(berrange) Quantum should pass the bridge name
    # in another binding metadata field
    if vif_type == network_model.VIF_TYPE_OVS:
        bridge = CONF.quantum_ovs_bridge
    elif vif_type == network_model.VIF_TYPE_BRIDGE:
        bridge = "brq" + port['network_id']

By the above, I think that Qauntum plugin used with vif-driver of Nova has to support Portbindings extension.

[Yoshihiro Kaneko (ykaneko0929)]

This issue was already reported.
  https://bugs.launchpad.net/quantum/+bug/1099894

[dan wendlandt (danwent)]

Yes, this is an issue due to a recent nova change. the fundemental issue seems to be that the patch changed the name of a config variable, because the goal of the patch was to pull this config out of the virt layer. However, there's no obvious way to do this in a backward compatible way.

My thinking on this would be to unwind the part of the patch that changes the config variable, and either have the bridge be passed back by quantum, or default to using the libvirt_ovs_bridge field. From daniel's comments, the quantum_ovs_bridge field config variable was a stepping-stone anyway.

[dan wendlandt (danwent)]

Adding Daniel B., as garyk says he is working on a patch to fix this.

[Daniel Berrange (berrange)]

FYI, I am working on a patch to handle back-compat correctly.

[dan wendlandt (danwent)]

Thanks Daniel.

Just to clear up some confusion I've seen from the quantum side, this is not ryu-specific, per-se.

I believe it would affect any use of Nova that uses a OVS-based vif-plugging type (i.e., any vif-plugging that formerly looked at the config value of libvirt_ovs_bridge).

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/19831
Committed: http://github.com/openstack/nova/commit/84341f7c51dca01c03d2d0a771f1afadc8b5131f
Submitter: Jenkins
Branch: master

commit 84341f7c51dca01c03d2d0a771f1afadc8b5131f
Author: Daniel P. Berrange <email address hidden>
Date: Wed Jan 16 16:55:05 2013 +0000

    Fix fallback when Quantum doesn't provide a 'vif_type'

    In

      commit 4babf7d7e12f35c137148727842f7af28312e858
      Author: Daniel P. Berrange <email address hidden>
      Date: Fri Jan 4 12:22:20 2013 +0000

        Make Quantum plugin fill in the 'bridge' name

    We changed libvirt VIF driver to pull 'bridge' out of the
    VIF model. This only worked for new Quantum drivers that
    provide the 'vif_type' portbinding metadata though. This
    patch effectively reverts part of that patch, so we have
    a combination of the new & old method for determining
    bridge names. The libvirt VIF driver will look at the
    network['bridge'] field first, and if missing will fallback
    to its previous logic which hardcoded bridge names.

    Bug: 1100199
    Change-Id: I5fd66b0303159c42bd227e97ddab381b2b67670c
    Signed-off-by: Daniel P. Berrange <email address hidden>