Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 2215624

Summary: Port edits through Horizon silently (re)set the port port binding profile to 'binding:vif_type': 'vrouter' at least for 'vhostuser' ports
Product: Red Hat OpenStack Reporter: Jacob Ansari <jansari>
Component: python-django-horizonAssignee: Owen McGonagle <omcgonag>
Status: CLOSED WORKSFORME QA Contact: Ashish Gupta <ashigupt>
Severity: medium Docs Contact:
Priority: medium    
Version: 16.2 (Train)CC: aruffin, eprado, fboboc, fpalin, gkadam, jansari, jjoyce, jlibosva, jpretori, jschluet, me, mlaniel, omcgonag, rdopiera, rhos-maint, skhandav, slinaber, tvignaud
Target Milestone: ---Keywords: Triaged
Target Release: ---Flags: omcgonag: needinfo-
omcgonag: needinfo-
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: 2024-07-24 13:14:55 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:
Embargoed:

Description Jacob Ansari 2023-06-16 19:12:45 UTC
Description of problem:

"Port edits through Horizon (re)set the port port binding profile to 'binding:vif_type': 'vrouter' when it is set to 'binding:vif_type': 'vhostuser' .  No option to override this is available in Horizon. Same port edit done through CLI preserves 'binding:vif_type': 'vhostuser' ".
The same change made throught OSP CLI does not present this issue.


Version-Release number of selected component (if applicable):


How reproducible:
100%

Steps to Reproduce:
1. In Horizon, edit a port with 'binding:vif_type': 'vhostuser' and save changes

Actual results:
Changes in edit take affect, BUT 'binding:vif_type' gets reset to 'vrouter'

Expected results:
Changes in edit take affect, AND 'binding:vif_type' remains 'vhostuser'

Additional info:

This is BZ a narrower scoped on based on https://bugzilla.redhat.com/show_bug.cgi?id=2184815 which was opened as an RFE . Regardless of the path the RFE takes, there is  appears to be a concrete issue here in how 'binding:vif_type' is handled in horizon vs the CLI .

Comment 3 Radomir Dopieralski 2023-07-26 12:14:10 UTC
*** Bug 2184815 has been marked as a duplicate of this bug. ***

Comment 9 Jakub Libosvar 2024-04-09 12:49:24 UTC
vif_type is set by Neutron to tell Nova which vif_driver it should use, it is not set by user and user cannot change it as API does not allow that: https://opendev.org/openstack/neutron-lib/src/branch/master/neutron_lib/api/definitions/portbindings.py#L179

I don't know how Horizon UI looks like but if there is a field that can set vif_type for port then this field should be either informative and read-only or removed completely.

It may be confusing but vif_type and vnic_type are two different fields - vnic_type is indeed configurable.

Comment 10 mlaniel 2024-04-22 16:50:00 UTC
The issue here is that `vif_type` changes when the user, using Horizon, edits a port.
User is *not* editing `vif_type`, but it's getting altered in the process, somehow.
So...In Horizon, editing a port that has `vif_type:vhostuser` will unexpectedly set `vif_type:vrouter` in our customer's case.
This cannot be reproduced with CLI.

Comment 11 Radomir Dopieralski 2024-04-23 07:03:16 UTC
Is it possible that vif_type is being reset to the default value every time vnic_type is set, even if it's set to the same value it had previously?

Comment 12 Owen McGonagle 2024-05-16 18:31:57 UTC
There are two issues
- Horizon UI does not allow for the binding_profile to change
- After editing a port - the binding_profile gets reset to 'vrouter'

Focusing on the initial error - where the binding_profile gets reset

Details are below
- I was unable to reproduce the error - where binding_profile gets reset to 'vrouter'

Question:
- Please review the steps below
- Is there a specific step/detail I am missing? Was unable to reproduce

Attempt to reproduce:

1. Show test_port with binding 'vhostuser'

(openstack) port show test_port
|-------------------+------------------------------|
| Field             | Value                        |
|-------------------+------------------------------|
| binding_profile   | binding:vif_type='vhostuser' |
| binding_vnic_type | normal                       |
|-------------------+------------------------------|

2. Edit the port through UI Project/Network/Networks/test_network/Ports/test_port

FROM: Binding -> VNIC Type -> Normal
TO:   Binding -> VNIC Type -> Direct

3. Check to see if binding_profile changes after port edig

Unable to reproduce - binding_profile remains the same

(openstack) port show test_port
|-------------------+------------------------------|
| Field             | Value                        |
|-------------------+------------------------------|
| binding_profile   | binding:vif_type='vhostuser' |
| binding_vnic_type | direct                       |
|-------------------+------------------------------|

Comment 13 dvd 2024-05-17 16:10:01 UTC
Hello,

The problem here is that, if the vnic_type is not part of this list [a], it's getting unset or set to the default (normal?). I wouldn't care much about that behaviour until it completely breaks networking for a production VM.

That being said, it's either you reuse the current values in case the value is not part of that list, or there's a custom option with a text-box field.

The current behaviour is unacceptable as it will stealthily change the vnic type for a port thus breaking networking for workload.

Thanks,

DVD

[a] https://github.com/openstack/horizon/blob/train-eol/openstack_dashboard/api/neutron.py#L67-L74

Comment 14 dvd 2024-05-17 16:12:34 UTC
(In reply to Owen McGonagle from comment #12)

You need to test with custom vnic_type, not binding profile.

Comment 15 Radomir Dopieralski 2024-05-21 12:25:28 UTC
Can you please provide the exact steps we can use to reproduce the problem? That is, the command line commands to create a port with correct parameters, and the steps to edit the port to trigger the problem? It seems that we are running around in circles here, being confused by different concepts with similar names. We are not very experienced with networking and will need your help to fix this.

Comment 16 Owen McGonagle 2024-06-04 14:59:18 UTC
Hi Jacob,

Could you please add the exact steps so that we can reproduce and fix this?

Thank you.
Owen.