Description of problem: ovn localnet: attachment of ovn network to Custom data center network is not displayed. When setting a custom data center network for ovn local net, it is not saved. Custom data center network is a long name=vdsm name Version-Release number of selected component (if applicable): 4.2.1.1-0.1.el7 How reproducible: 100% Steps to Reproduce: 1. Create long name(more then 15 characters) and attach to host 2. Take it's vdsm name and create new ovn network and set in the custom filed the vdsm name 3. Press OK and edit the network Actual results: The custom name is gone Expected results: Should be displayed
This bug has very little to do with long names. If a user defines an external network backed up by a localnet, and passes Custom brdige name and segmentation id, the custom values do not show up when the external network details are viewed. This is because the Custom values are stored in the external provider, and the front-end (nor REST) fetches info only from Engine db. I think that it would be nice to attempt to pull the information from the provider, and present it in UI and REST.
It is possible to pull the information. But the problem is how to represent it into our existing structure? VLAN tag is the same for both. The "provider:physical_network" which is vdsm switch name has no representation in our Network structure. In the UI there is way around to properly display it. REST would be able to display only VLAN tag. So is it ok?
I don't really understand your question. I *thought* that for "Custom" values we have plain strings to select both vdsm bridge name and vlan. They are passed verbatim to the provider. Am I mistaken? Do we perform some non-reversable function onto these values?
You are right but we have no representation for the "custom" value in engine network entity. We are passing the value into provider via label. In the UI it doesn't really matter. This is problem for the REST as the "custom" name (vdsm bridge name) cannot be displayed there.
We need "custom" only for backward compatibility. So no need to worry about exposing it in REST if there is no field for it yet. The current UI, however, is "write-only" and quite confusing. I hope you can fix it.
Testing on - 4.2.6_SNAPSHOT-84.gad3de30.0.scratch.master.el7ev Custom bridge is populated in UI and REST. Start VM is working, but the custom bridge/vlan is not passed to guest and VM won't get the IP from the custom vlan network as it should. "status": "ACTIVE", "name": "test-local-net", "provider:physical_network": "on7ac5f1d5d5d94", "tenant_id": "00000000000000000000000000000001", "provider:network_type": "flat", "id": "3a72a74a-943f-4bb4-9d8c-f0069dd7b6c9", "mtu": 1442 Port "on7ac5f1d5d5d94" tag: 163 Interface "on7ac5f1d5d5d94" type: internal Port "eno2" Interface "eno2" Guest should get an IP from vlan 163 in this case, but actually gets the native one and not 163. This can't be verified, moving back to assigned
After speaking with Dominik, i have reported new bug BZ 1608885, as this is a new functional problem and the current bug can be verified
Verified on - 4.2.6_SNAPSHOT-84.gad3de30.0.scratch.master.el7ev Custom bridge is populated in UI and REST
This bugzilla is included in oVirt 4.2.5 release, published on July 30th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.5 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.