Bug 967608 - engine: create storage domain is failing after 2 minutes although command completed successfully in vdsm after 2:04 [NEEDINFO]
engine: create storage domain is failing after 2 minutes although command com...
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal (Show other bugs)
3.3.0
x86_64 Linux
unspecified Severity high
: ---
: 3.4.0
Assigned To: Alexander Wels
Leonid Natapov
ux
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-27 10:49 EDT by Haim
Modified: 2015-09-22 09 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-08 11:15:16 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
awels: needinfo? (hateya)


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

  None (edit)
Description Haim 2013-05-27 10:49:05 EDT
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 10:51:22 EDT
Created attachment 753648 [details]
vdsm logs.
Comment 2 Haim 2013-05-27 10:55:20 EDT
Created attachment 753650 [details]
engine.log
Comment 3 Ayal Baron 2013-07-17 05:47:58 EDT
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 15:54:35 EDT
(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 10:25:45 EDT
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?

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