Bug 918039

Summary:	[RFE] Decouple DWH and engine
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Alon Bar-Lev <alonbl>
Component:	ovirt-engine	Assignee:	Barak <bazulay>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	acathrow, emesika, iheim, jkt, lpeer, Rhev-m-bugs, yeylon, ylavi
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	3.2.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	infra
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-12-01 23:03:16 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Alon Bar-Lev 2013-03-05 11:19:35 UTC

CURRENT STATE

engine updates statistics in database.
dwh does not know if statistics are valid.
as a result dwh pulls engine using http and if engine is up it assumes statistics are valid (updated).

PROBLEM IN CURRENT STATE

dwh should be decoupled from engine, and monitor only database, the fact that it is initiating http request to the engine is redundant, it requires network privileges/reachability and extra communications.

SOLUTION

When engine update statistics it should also update a specific column (can be in vdc_options or any) with the timestamp of last statistics update.

This way the dwh can determine if statistics are valid or not without interacting directly with the engine.

Comment 1 Dan Yasny 2013-03-05 15:03:06 UTC

Setting on future for now. Barak, feel free to move to 3.3 if you decide it's feasible

Comment 2 Itamar Heim 2013-03-08 14:07:05 UTC

should't be on every stat update - its a multithreaded stats update.
can probably just a thread to update the config every x seconds or something like that, which would only work while engine is up anyway.

Comment 3 Alon Bar-Lev 2013-03-08 15:47:28 UTC

(In reply to comment #2)
> should't be on every stat update - its a multithreaded stats update.
> can probably just a thread to update the config every x seconds or something
> like that, which would only work while engine is up anyway.

Question if less resources to do this within the stored procedure that updates the stats or perform another query. I am unsure if decoupled interval query is less resources. But never the less, will be a better solution than the existing implementation.

Comment 4 Itamar Heim 2013-12-01 19:09:32 UTC

eli - thoughts?

Comment 5 Yaniv Lavi 2013-12-01 23:03:16 UTC

This is in since 3.2. Closing.


Yaniv

Comment 6 Eli Mesika 2013-12-02 09:41:19 UTC

(In reply to Itamar Heim from comment #4)
> eli - thoughts?

I think that having a field in the database for that is OK, however , I don't think that this is a configuration value so I would not put that in vdc_options rather in a separate table (engine_status or something like that) that will be a place holder for future needs as well.

I like more the a thread in the BLL that will update this field periodically rather than putting that inside the SPs since we will have to put that in multiple places and we may be facing deadlock issues and such stuff. So , another thread doing the update every let say 1 min will be perfect.

Comment 7 Yaniv Lavi 2013-12-02 14:26:18 UTC

(In reply to Eli Mesika from comment #6)
> (In reply to Itamar Heim from comment #4)
> > eli - thoughts?
> 
> I think that having a field in the database for that is OK, however , I
> don't think that this is a configuration value so I would not put that in
> vdc_options rather in a separate table (engine_status or something like
> that) that will be a place holder for future needs as well.
> 
> I like more the a thread in the BLL that will update this field periodically
> rather than putting that inside the SPs since we will have to put that in
> multiple places and we may be facing deadlock issues and such stuff. So ,
> another thread doing the update every let say 1 min will be perfect.

This is done via heartbeat async module mperina has implemented.



Yaniv