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-horizon | Assignee: | 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
*** Bug 2184815 has been marked as a duplicate of this bug. *** 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. 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. 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? 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 | |-------------------+------------------------------| 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 (In reply to Owen McGonagle from comment #12) You need to test with custom vnic_type, not binding profile. 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. Hi Jacob, Could you please add the exact steps so that we can reproduce and fix this? Thank you. Owen. |