Bug 1377963 - For OVN ports Interface:external_ids:iface-id requires Logical-Switch-Port name instead of id
Summary: For OVN ports Interface:external_ids:iface-id requires Logical-Switch-Port na...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openvswitch
Version: 7.4
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Russell Bryant
QA Contact: ovs-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-21 07:59 UTC by Marcin Mirecki
Modified: 2016-11-07 21:26 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-07 21:26:38 UTC
Target Upstream Version:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.