Bug 1390936

Summary:	[CodeChange] move vdsm calls (mostly removeImage) from transactional endAction()
Product:	[oVirt] ovirt-engine	Reporter:	Liron Aravot <laravot>
Component:	BLL.Storage	Assignee:	Fred Rolland <frolland>
Status:	CLOSED UPSTREAM	QA Contact:	Elad <ebenahar>
Severity:	high	Docs Contact:
Priority:	high
Version:	4.1.0	CC:	acanan, amureini, bugs, ebenahar, frolland, jentrena, lsurette, mperina, pdwyer, rbalakri, Rhev-m-bugs, srevivo, tnisan, ykaul, ylavi
Target Milestone:	ovirt-4.2.1	Keywords:	CodeChange, Tracking, ZStream
Target Release:	---	Flags:	rule-engine: ovirt-4.2? rule-engine: ovirt-4.3? rule-engine: planning_ack? rule-engine: devel_ack? rule-engine: testing_ack?
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1372743
Clones:	1455871 (view as bug list)		Environment:
Last Closed:	2018-03-12 12:46:18 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Storage	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1455871

Description Liron Aravot 2016-11-02 09:46:06 UTC

Currently some flows has vdsm calls (mostly removeImage) performed on the endAction() method. If the endAction() is executed within transaction we might get a transaction timeout on some scenarios.
This RFE is about moving those calls out of the endAction() - In order to do that:
1. Our "COCO-Storage" infrastructure (serial callback) needs to be modified to support moving vdsm calls out of endWithFailure().
2. The relevant flows needs to start using the COCO infrastructure instead of relying on the tasks infrastructure.

Comment 1 Yaniv Lavi 2016-11-23 08:30:11 UTC

Can you describe the functional impact?

Comment 2 Liron Aravot 2016-12-22 16:02:06 UTC

Sure,
The functional impact is that we may get transaction timeouts when executing vdsm calls within transactional endAction(). 
In BZ 1372743 (see https://bugzilla.redhat.com/show_bug.cgi?id=1372743#c22) it caused us to remain with a locked disk.

Let me know if further info is needed.

Thanks,
Liron

Comment 3 Yaniv Lavi 2016-12-28 12:39:09 UTC

Tal, I'm treating this as code change. Please decide on a target for it.

Comment 6 Yaniv Kaul 2018-03-12 10:03:59 UTC

Downstream clone is VERIFIED, but this is on NEW?