Bug 1377963

Summary: For OVN ports Interface:external_ids:iface-id requires Logical-Switch-Port name instead of id
Product: Red Hat Enterprise Linux 7 Reporter: Marcin Mirecki <mmirecki>
Component: openvswitchAssignee: Russell Bryant <rbryant>
Status: CLOSED NOTABUG QA Contact: ovs-qe
Severity: medium Docs Contact:
Priority: medium    
Version: 7.4CC: aloughla, atragler, fleitner
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-07 21:26:38 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Marcin Mirecki 2016-09-21 07:59:06 UTC
I have a problem with the Interface external_ids:iface-id property in OVN
To configure an ovs port on the host for OVN, you need to set the value of
this property to the name of the Logical-Switch-Port from the NorthDB:
ovs-vsctl add-port br-int lport1 -- set Interface lport1 external_ids:iface-id=sw0-port1

This is using the name, not the id.
Specifying the id does not work.
This is ok when you do it by hand, but is inconvenient when you try to
automate it.
Libvirt offers a chance to automate deployment of ovs connected nics, but it 
only accepts an UUID value, so using the name makes this impossible.

Would it be possible for OVN to interpret both values (I realize this
would cause some issues)?


For reference, the way to set this in libvirt xml:
<interface>
    ...
         <virtualport type='openvswitch'>
           <parameters interfaceid='lsp-name'/>
         </virtualport>
Using the name results in:
libvirtError: XML error: cannot parse interfaceid parameter as a uuid

Another disadvantage is that this forces the LSP name to be unique,
unlike for example Logical-Switch names, which can be duplicated.

We have a workaround, but it causes some unneccessary complications.

Comment 2 Russell Bryant 2016-11-07 21:26:38 UTC
Further discussion with Marcin has indicated that they were able to work around this issue in an acceptable way and no longer need changes here.