Bug 862463
Summary: | RFE: ovs-vsctl: report ovs-vswitchd warnings and errors resulting directly from a ovs-vsctl command | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jean-Tsung Hsiao <jhsiao> | ||||
Component: | openvswitch | Assignee: | Thomas Graf <tgraf> | ||||
Status: | CLOSED CANTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 17 | CC: | akong, amwang, chrisw, jhsiao, kdube, markmc, rkhan, tgraf | ||||
Target Milestone: | --- | Keywords: | FutureFeature | ||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Enhancement | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2013-02-12 12:04:29 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: | |||||||
Attachments: |
|
Description
Jean-Tsung Hsiao
2012-10-03 02:05:07 UTC
A similar issue was found when more than 1024 ports were added. "ovsctl add-port" didn't respond with warning or error. But, the failure messages were found in ovs-vswitchd.log: 2012-10-05T15:49:15Z|18689|dpif|WARN|system@ovsbr: failed to add ovsbrT1017 as port: Device or resource busy 2012-10-05T15:49:15Z|18690|dpif|WARN|system@ovsbr: failed to add ovsbrT1017 as port: Device or resource busy 2012-10-05T15:49:15Z|18691|dpif|WARN|system@ovsbr: failed to add ovsbrT1018 as port: Device or resource busy 2012-10-05T15:49:15Z|18692|dpif|WARN|system@ovsbr: failed to add ovsbrT1017 as port: Device or resource busy 2012-10-05T15:49:15Z|18693|dpif|WARN|system@ovsbr: failed to add ovsbrT1019 as port: Device or resource busy 2012-10-05T15:49:15Z|18694|dpif|WARN|Dropped 1 log messages in last 1 seconds (most recently, 1 seconds ago) due to excessive rate 2012-10-05T15:49:15Z|18695|dpif|WARN|system@ovsbr: failed to add ovsbrT1020 as port: Device or resource busy I think this is not a bug. Take the example from Thomas' tutorial: ovs-vsctl -- add-port ovsbr0 vlan10 \ tag=10 -- set Interface vlan10 \ type=internal in this case, vlan10 doesn't exist before this command. And the above command equals to: ovs-vsctl add-port ovsbr0 vlan10 tag=10 ovs-vsctl set Interface vlan10 type=internal so after the first one executed, vlan10 is already added to the ovs bridge, but not to the kernel, because its type is incomplete currently: # ovs-vsctl get Interface non-exist type "" The second command just sets its type to be internal and commits it to the kernel finally. Therefore, ovs-vsctl doesn't consider this as an error, just shows some warning in the log. ^^^ should be: ovs-vsctl get Interface vlan10 type Anyway, its type is still incomplete after "ovs-vsctl add-port ovsbr0 vlan10 tag=10". Thomas points out that when the name of the interface is invalid, for example too long, ovs-vsctl should return some error before passing it to the kernel. This makes sense. Created attachment 632673 [details]
Proposed patch
After this patch:
# ovs-vsctl add-port ovsbr0 12345678901234567890
ovs-vsctl: cannot create a port named 12345678901234567890 because the name is not valid
# ovs-vsctl add-br 12345678901234567890
ovs-vsctl: cannot create a bridge named 12345678901234567890 because the name is not valid
I would suggest making the command more friendly by giving warnigs about potential issues. Another similar issue: When eth1 and eth0 are bonded with "lapcp=active", ovs-vsctl responded with enabled for both interfaces. But, both get disabled right away --- see below. 2012-10-16T21:43:34Z|00677|bond|INFO|interface eth0: link state down 2012-10-16T21:43:34Z|00678|bond|WARN|interface eth0: disabled 2012-10-16T21:43:34Z|00679|bond|INFO|interface eth1: link state down 2012-10-16T21:43:34Z|00680|bond|WARN|interface eth1: disabled 2012-10-16T21:45:49Z|00681|bond|WARN|interface eth0: enabled 2012-10-16T21:45:49Z|00682|bond|INFO|interface eth0: link state down 2012-10-16T21:45:49Z|00683|bond|WARN|interface eth0: disabled 2012-10-16T21:45:53Z|00684|bond|WARN|interface eth1: enabled 2012-10-16T21:45:53Z|00685|bond|INFO|interface eth1: link state down 2012-10-16T21:45:53Z|00686|bond|WARN|interface eth1: disabled (In reply to comment #6) Jean, the bond issue should be a different one, please report a new BZ for it. All the mentioned usability issues are due to the warnings emitted by the switching daemon not being pushed to the CLI invoking the action. There is no point in duplicating all the verification and error checking code in ovs-vsctl, instead the warnings should be reported back properly. I realize this is not trivial to the possible remote nature of ovs-vsctl but it's the only clean way to resolve this long term. I consider this more of an RFE rather than a bug though. Hi Cong, I'll do. Thanks! Jean Hi Thomas, I have no issue about an RFE for this issue. Thanks! Jean *** Bug 972307 has been marked as a duplicate of this bug. *** |