Bug 967608 - engine: create storage domain is failing after 2 minutes although command completed successfully in vdsm after 2:04
Summary: engine: create storage domain is failing after 2 minutes although command com...
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal
Version: 3.3.0
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
: 3.4.0
Assignee: Alexander Wels
QA Contact: Leonid Natapov
URL:
Whiteboard: ux
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-27 14:49 UTC by Haim
Modified: 2023-09-14 01:44 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-10-08 15:15:16 UTC
oVirt Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
vdsm logs. (896.75 KB, application/gzip)
2013-05-27 14:51 UTC, Haim
no flags Details
engine.log (24.85 KB, application/gzip)
2013-05-27 14:55 UTC, Haim
no flags Details

Description Haim 2013-05-27 14:49:05 UTC
Description of problem:

problem: timeout in web-admin is not synced with vds for creatStorageDomain command (guess for sync command).
timeout is set to 120 seconds while in engine\vdsm its 180.

in my case, createStorageDomain is taking longer than 2 minutes (2:04) hence transaction is rolled back and operation fails in engine although it was successful in vdsm.

user impact:

- engine and vdsm are not synced, domain is created but engine doesn't know about it

repro steps:

1) install engine + vdsm based on 3.3 version
2) add new host
3) run 'yum install gluster* -y'
4) reboot host
5) add new storage domain from type glusterfs

due to bz 967596, creation of SD took more then 2 minutes, so operation failed.

Comment 1 Haim 2013-05-27 14:51:22 UTC
Created attachment 753648 [details]
vdsm logs.

Comment 2 Haim 2013-05-27 14:55:20 UTC
Created attachment 753650 [details]
engine.log

Comment 3 Ayal Baron 2013-07-17 09:47:58 UTC
Storage side the only way to solve this is change all verbs to be async.
Wrt 180/120 - engine has a 180s timeout for all vdsm ops and this timeout has been heavily tested and it would be a very bad idea to change it.
The only relevant solution I see here is to change the webadmin timeout to 120.
Einav?

Comment 4 Einav Cohen 2013-08-27 19:54:35 UTC
(In reply to Ayal Baron from comment #3)
> Storage side the only way to solve this is change all verbs to be async.
> Wrt 180/120 - engine has a 180s timeout for all vdsm ops and this timeout
> has been heavily tested and it would be a very bad idea to change it.
> The only relevant solution I see here is to change the webadmin timeout to
> 120.
> Einav?

I am not aware of any timeout - but assigning Alex to investigate.

Comment 5 Alexander Wels 2013-08-28 14:25:45 UTC
I checked and I am not aware of any timeout either, I double checked with Vojtech and he didn't know of any timeout either. May I ask what you mean with webadmin timeout. I checked the configuration between the engine and VDSM and I found a couple of potential candidates but I am not 100% sure what they mean:

1. ServerRebootTimeout (???)
2. NetworkConnectivityCheckTimeoutInSeconds (Timeout to wait when making network changes?)
3. ExternalSchedulerResponseTimeout (Related to scheduler?)

Other than that I have no clue what you mean by webadmin timeout, could you please elaborate?

Comment 6 Red Hat Bugzilla 2023-09-14 01:44:34 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days


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