Bug 1303583 - [BLOCEKD][scale] Long waits when editing existing iscsi [data] domains on populated enviroment
Summary: [BLOCEKD][scale] Long waits when editing existing iscsi [data] domains on pop...
Keywords:
Status: CLOSED DUPLICATE of bug 1303578
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Storage
Version: 3.6.2.5
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ovirt-4.1.0-alpha
: ---
Assignee: Fred Rolland
QA Contact: Aharon Canan
URL:
Whiteboard:
Depends On: 1303578
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-02-01 11:26 UTC by mlehrer
Modified: 2016-06-28 10:58 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-06-28 10:58:56 UTC
oVirt Team: Storage
Embargoed:
amureini: ovirt-4.1?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?

Attachments (Terms of Use)
16luns 1sd log (924.76 KB, text/x-vhdl)
2016-02-01 11:26 UTC, mlehrer 		no flags Details
View All

Description mlehrer 2016-02-01 11:26:18 UTC 
Created attachment 1120072 [details]
16luns 1sd log

Description of problem:

Clicking the "edit" storage domain in ovirt-engine UI in order to edit an existing storage iscsi (data) domain with 100 exposed luns can take around 1 minute.

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

vdsm-python-4.17.17-0.el7ev.noarch
vdsm-yajsonrpc-4.17.17-0.el7ev.noarch
vdsm-4.17.17-0.el7ev.noarch
vdsm-xmlrpc-4.17.17-0.el7ev.noarch
vdsm-jsonrpc-4.17.17-0.el7ev.noarch
vdsm-cli-4.17.17-0.el7ev.noarch
vdsm-infra-4.17.17-0.el7ev.noarch

ovirt-vmconsole-proxy-1.0.0-1.el6ev.noarch
libgovirt-0.3.2-1.el6.x86_64
rhevm-setup-plugin-ovirt-engine-common-3.6.2.5-0.1.el6.noarch
ovirt-engine-extension-aaa-jdbc-1.0.5-1.el6ev.noarch
ovirt-setup-lib-1.0.1-1.el6ev.noarch
rhevm-setup-plugin-ovirt-engine-3.6.2.5-0.1.el6.noarch
ovirt-host-deploy-java-1.4.1-1.el6ev.noarch
ovirt-host-deploy-1.4.1-1.el6ev.noarch
ovirt-vmconsole-1.0.0-1.el6ev.noarch


How reproducible:
Very

Steps to Reproduce:
1. expose 100 luns to hosts
2. create data domain from multiple luns for 1 iscsi SD
3. Click "edit" storage domain from UI

Actual results:


42s for 40 luns 1 SD  
41s for 7  luns 1 SD 
45s for 16 luns 1 SD

Expected results:
Similar behavior as editing any other storage [data] domain, with UI response within 3-4 seconds, and warning message for the user if more time is needed.

Additional info:

Likely related to https://bugzilla.redhat.com/show_bug.cgi?id=1303578

In which GetDeviceListVDSCommand makes mulitple sequential calls, and takes around 7-10s per call.
Comment 1 Fred Rolland 2016-06-16 08:34:00 UTC 
The root cause for this issue is https://bugzilla.redhat.com/show_bug.cgi?id=1303578 .

I think we can duplicate this one to it.
Comment 2 mlehrer 2016-06-28 10:44:03 UTC 
(In reply to Fred Rolland from comment #1)
> The root cause for this issue is
> https://bugzilla.redhat.com/show_bug.cgi?id=1303578 .
> 
> I think we can duplicate this one to it.

Makes sense.
Comment 3 Fred Rolland 2016-06-28 10:58:56 UTC 

*** This bug has been marked as a duplicate of bug 1303578 ***
Note You need to log in before you can comment on or make changes to this bug.