Bug 1403653 - [RFE] Should accept any bond name starting with bond
Summary: [RFE] Should accept any bond name starting with bond
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Network
Version: ---
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ovirt-4.3.0
: 4.3.0
Assignee: Ales Musil
QA Contact: Michael Burman
URL:
Whiteboard:
Depends On: 1624069
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-12-12 06:06 UTC by Huijuan Zhao
Modified: 2019-04-24 20:56 UTC (History)
16 users (show)

Fixed In Version: ovirt-engine-4.3.0_alpha
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-13 07:44:58 UTC
oVirt Team: Network
Embargoed:
rule-engine: ovirt-4.3+
mburman: testing_plan_complete+
ylavi: planning_ack+
danken: devel_ack+
mburman: testing_ack+


Attachments (Terms of Use)
All logs and all files in /etc/sysconfig/network-scripts (8.30 MB, application/x-gzip)
2016-12-12 06:06 UTC, Huijuan Zhao
no flags Details
Screenshot of invalid bond name (139.75 KB, image/png)
2016-12-12 06:07 UTC, Huijuan Zhao
no flags Details
Screenshot of networking after failed adding rhvh to rhvm (111.23 KB, image/png)
2016-12-12 06:09 UTC, Huijuan Zhao
no flags Details
Comment 5: error exposed to user (256.58 KB, image/png)
2016-12-20 09:40 UTC, Huijuan Zhao
no flags Details
Comment 5: engine.log in engine side (1.48 MB, application/x-gzip)
2016-12-20 09:41 UTC, Huijuan Zhao
no flags Details


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 95163 0 master MERGED backend, webadmin: Enable custom bond names 2020-05-04 22:12:06 UTC
oVirt gerrit 95454 0 master MERGED webadmin: Rephrase custom bond name error message 2020-05-04 22:12:06 UTC
oVirt gerrit 95671 0 master MERGED webadmin: Change the 'must' in the custom bond name 2020-05-04 22:12:06 UTC

Description Huijuan Zhao 2016-12-12 06:06:34 UTC
Created attachment 1230704 [details]
All logs and all files in /etc/sysconfig/network-scripts

Description of problem:
There is not prompt message when input invalid bond name in network setting page via cockpit, and can take effect after set up invalid bond name.
In fact, we only support the bond name as bond[0-99], if we setup invalid bond name such as bd0, this will cause adding rhvh to rhvm failed.
There should be prompt message to prevent setting invalid bond name via cockpit.

Version-Release number of selected component (if applicable):
redhat-virtualization-host-4.0-20161206.0
cockpit-ws-122-3.el7.x86_64
NetworkManager-1.4.0-13.el7_3.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Install RHVH 4.0.6 via anaconda.
2. Reboot RHVH and login cockpit, enter Networking page in cockpit
3. Create bond which named bd0 over one NIC em1
4. Add rhvh to rhvm with bond bd0

Actual results:
In step3, there is not prompt message, can set bd0 successful
In step4, add rhvh to rhvm failed

Expected results:
In step3, There should be prompt message to prevent setting invalid bond name via cockpit, and should set up bond failed with invalid bond name.

Additional info:

Comment 1 Huijuan Zhao 2016-12-12 06:07:48 UTC
Created attachment 1230705 [details]
Screenshot of invalid bond name

Comment 2 Huijuan Zhao 2016-12-12 06:09:19 UTC
Created attachment 1230706 [details]
Screenshot of networking after failed adding rhvh to rhvm

Comment 3 Fabian Deutsch 2016-12-12 07:37:28 UTC
Moving this back to RHEV, because it seems to be a limitation of vdsm.

Comment 4 Dan Kenigsberg 2016-12-20 08:39:50 UTC
Both Engine and Vdsm support only bond+number bondnames. But when and how does adding a node fail? What is the error exposed to the user? Can you attach engine.log? (I could not find it in the big sosreport dump)

Comment 5 Huijuan Zhao 2016-12-20 09:38:47 UTC
(In reply to Dan Kenigsberg from comment #4)
> Both Engine and Vdsm support only bond+number bondnames. But when and how
> does adding a node fail? What is the error exposed to the user? Can you
> attach engine.log? (I could not find it in the big sosreport dump)

After setup bond with name bd0 on node, when adding the node to engine with bd0, it failed when configure management network on node. Please refer to attachment for detailed error and engine.log.

Comment 6 Huijuan Zhao 2016-12-20 09:40:31 UTC
Created attachment 1233768 [details]
Comment 5: error exposed to user

Comment 7 Huijuan Zhao 2016-12-20 09:41:42 UTC
Created attachment 1233769 [details]
Comment 5: engine.log in engine side

Comment 8 Huijuan Zhao 2016-12-20 09:44:02 UTC
(In reply to Huijuan Zhao from comment #5)

> After setup bond with name bd0 on node, when adding the node to engine with
> bd0, it failed when configure management network on node. Please refer to
> attachment for detailed error and engine.log.

Additional info:
vdsmd status on node after failed adding node to engine:
# systemctl status vdsmd
● vdsmd.service - Virtual Desktop Server Manager
   Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2016-12-20 09:28:09 GMT; 6min ago
 Main PID: 24151 (vdsm)
   CGroup: /system.slice/vdsmd.service
           └─24151 /usr/bin/python /usr/share/vdsm/vdsm

Dec 20 09:28:10 ibm-x3650m5-04.lab.eng.pek2.redhat.com python[24151]: DIGEST-MD5 ask_user_info()
Dec 20 09:28:10 ibm-x3650m5-04.lab.eng.pek2.redhat.com python[24151]: DIGEST-MD5 client step 1
Dec 20 09:28:10 ibm-x3650m5-04.lab.eng.pek2.redhat.com python[24151]: DIGEST-MD5 ask_user_info()
Dec 20 09:28:10 ibm-x3650m5-04.lab.eng.pek2.redhat.com python[24151]: DIGEST-MD5 make_client_response()
Dec 20 09:28:10 ibm-x3650m5-04.lab.eng.pek2.redhat.com python[24151]: DIGEST-MD5 client step 2
Dec 20 09:28:10 ibm-x3650m5-04.lab.eng.pek2.redhat.com python[24151]: DIGEST-MD5 parse_server_challenge()
Dec 20 09:28:10 ibm-x3650m5-04.lab.eng.pek2.redhat.com python[24151]: DIGEST-MD5 ask_user_info()
Dec 20 09:28:10 ibm-x3650m5-04.lab.eng.pek2.redhat.com python[24151]: DIGEST-MD5 make_client_response()
Dec 20 09:28:10 ibm-x3650m5-04.lab.eng.pek2.redhat.com python[24151]: DIGEST-MD5 client step 3
Dec 20 09:28:14 ibm-x3650m5-04.lab.eng.pek2.redhat.com vdsm[24151]: vdsm vds ERROR u'bd0' is not a valid bonding device name
                                                                    Traceback (most recent call last):
                                                                      File "/usr/share/vdsm/API.py", line 1473, in setupNetworks...
Hint: Some lines were ellipsized, use -l to show in full.

Comment 9 Dan Kenigsberg 2018-04-04 08:29:48 UTC
I am not sure we must support just ANY bond name; but we should allow more significant names with the `bond` prefix.

Comment 10 Dan Kenigsberg 2018-04-11 08:06:36 UTC
I'd like to support only names such as "bond20g" (bond*)

Comment 11 Michael Burman 2018-10-16 10:13:55 UTC
Note that this RFE shouldn't be backported to 4.2.z, only for 4.3

Comment 12 Michael Burman 2018-11-06 12:21:57 UTC
Ales, could you please add example or explanation to what kind of custom bond names are acceptable and which not?

Thanks,

Comment 13 Ales Musil 2018-11-06 12:36:13 UTC
The format is: "bond" followed by any printable ASCII character (a-z A-Z 0-9 _).
Length is 15 characters max.

Comment 14 Michael Burman 2018-11-06 12:40:14 UTC
(In reply to Ales Musil from comment #13)
> The format is: "bond" followed by any printable ASCII character (a-z A-Z 0-9
> _).
> Length is 15 characters max.

Oh ok, what will happen if my custom bond name has 13 characters and i'm attaching a vlan tagged network to it with tag 166? what will be with the max 15 characters?

Comment 15 Ales Musil 2018-11-06 13:20:45 UTC
Good point thanks for bringing it up. It actually blows vdsm so we need to limit it to 10 characters or do another approach.

Comment 16 Dan Kenigsberg 2018-11-06 15:17:25 UTC
Is it any different with currently-supported bond12345678901 ?

Comment 17 Michael Burman 2018-12-12 14:41:56 UTC
Verified on - 4.3.0-0.6.alpha2.el7

Comment 18 Sandro Bonazzola 2019-02-13 07:44:58 UTC
This bugzilla is included in oVirt 4.3.0 release, published on February 4th 2019.

Since the problem described in this bug report should be
resolved in oVirt 4.3.0 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.


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