Bug 1024028 - [RFE] [dwh] add trigger to stop etl connection via engine db value.
Summary: [RFE] [dwh] add trigger to stop etl connection via engine db value.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-core
Version: 3.4
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
: 3.5.1
Assignee: Yedidyah Bar David
QA Contact: Pavel Stehlik
URL:
Whiteboard: integration
Depends On: 1023754
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-28 15:55 UTC by Yaniv Lavi
Modified: 2016-04-04 11:52 UTC (History)
11 users (show)

Fixed In Version: ovirt-3.5.1_rc1
Doc Type: Enhancement
Doc Text:
Clone Of: 1023754
Environment:
Last Closed: 2015-01-21 16:03:37 UTC
oVirt Team: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 20657 0 None MERGED packaging: add upgrade flag to cause DWH to disconnect from db 2020-11-04 08:38:08 UTC
oVirt gerrit 34566 0 master MERGED packaging: setup: Stop remote dwh 2020-11-04 08:38:07 UTC
oVirt gerrit 34817 0 ovirt-engine-3.5 MERGED packaging: setup: Stop remote dwh 2020-11-04 08:38:08 UTC

Description Yaniv Lavi 2013-10-28 15:55:23 UTC
Description of problem:
When upgrading engine there needs to be an ability to stop all connection including the etl connections. We need to add trigger to cause etl to disconnect when it is installed remotely.

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

Comment 1 Yaniv Lavi 2013-10-29 14:36:14 UTC
Please base your work on patch:
http://gerrit.ovirt.org/20657

That adds the dwh disconnection flag.
At upgrade start change the value to '1' with this commmend:
"
UPDATE dwh_history_timekeeping
   SET var_value = '1'
 WHERE var_name = 'DisconnectDWH';
"
And at the end please change it back to '0' using:
"
UPDATE dwh_history_timekeeping
   SET var_value = '0'
 WHERE var_name = 'DisconnectDWH';
"

Do you require any more info?

Yaniv

Comment 2 Alon Bar-Lev 2013-10-29 15:08:14 UTC
I thought barak wanted to put it in vdc_options...

Anyway... we need 3 state...

I suggest:

0 - run as usual - set by setup, read by dwh
1 - stop - set by setup, read by dwh
2 - stopped - set by dwh, read by setup, read by dwh (in case of restart)

Comment 3 Yaniv Lavi 2013-10-29 16:11:29 UTC
(In reply to Alon Bar-Lev from comment #2)
> I thought barak wanted to put it in vdc_options...
> 
> Anyway... we need 3 state...
> 
> I suggest:
> 
> 0 - run as usual - set by setup, read by dwh
> 1 - stop - set by setup, read by dwh
> 2 - stopped - set by dwh, read by setup, read by dwh (in case of restart)

Moved to vdc_options and created two variables:
DisconnectDWH - for upgrade to set in order to disconnect dwh.
DWHCurrentlyRunning - set by etl at start and stop for upgrade to check.

See patch set 2 for the change


Yaniv

Comment 4 Yaniv Lavi 2014-01-12 15:28:08 UTC
Update on this:
http://gerrit.ovirt.org/#/c/20657/
Pushed changes to patches. DWHCurrentlyRunning was moved to dwh_history_timekeeping, DisconnectDWH is still in vdc_options.

ETL check the DisconnectDWH every 4 seconds. Once it's down DWHCurrentlyRunning will be set to 0. Upgrade need to set DisconnectDWH, so ETL will shutdown or will not start, and check that DWHCurrentlyRunning is or changes to 0.

Watchdog will reload the etl after an hour.


Yaniv

Comment 5 Alon Bar-Lev 2014-01-16 22:10:07 UTC
this is required only when we are to split dwh to different host, hence not for 3.4.

Comment 6 Sandro Bonazzola 2014-01-17 09:21:24 UTC
(In reply to Alon Bar-Lev from comment #5)
> this is required only when we are to split dwh to different host, hence not
> for 3.4.

Re-targeting to 3.5.

Comment 7 Sandro Bonazzola 2014-01-17 09:35:05 UTC
Adding to the already descripted logic:
supposing DWHCurrentlyRunning == 1 and DWH dead, we'll consider it unresponsive and we'll abort after 15 seconds (chosen as mid value between a min of 8 and a max of 30 seconds)

Comment 8 Itamar Heim 2014-02-13 18:31:22 UTC
pushing to target release 3.5, assuming its not planned for 3.4 at this point...

Comment 9 Yaniv Lavi 2014-06-12 11:42:04 UTC
Very important due to dwh and engine separation in 3.5.0.


Yaniv

Comment 11 Yedidyah Bar David 2014-07-21 10:04:23 UTC
Wouldn't it be better to (also) use listen/notify [1]?

IIRC we already discussed this (Yaniv and me), not sure what was the conclusion.

[1] http://www.postgresql.org/docs/8.3/static/sql-notify.html

Comment 12 Eli Mesika 2014-07-22 10:59:00 UTC
(In reply to Yedidyah Bar David from comment #11)
> Which code will use Listen/Notify ???

If this is done from the application you should pull the database for new notifications. (no real "push" support)

If JDBC is used, you need to run some kind of SELECT statement and then any pending notification will be available on the Connection object 

See
http://jdbc.postgresql.org/documentation/head/listennotify.html

Comment 13 Yedidyah Bar David 2014-08-07 12:28:54 UTC
I see that the 3.4 clone is closed. Is there anything else needed for 3.5?

Comment 14 Yaniv Lavi 2014-08-07 12:32:33 UTC
(In reply to Yedidyah Bar David from comment #13)
> I see that the 3.4 clone is closed. Is there anything else needed for 3.5?

implement the engine side of this process. change the flag and test dwh is off.

Comment 15 Shirly Radco 2014-09-03 08:27:01 UTC
This will also be relevant for RFE Bug 1136726.

Comment 16 Sandro Bonazzola 2015-01-15 14:15:27 UTC
This is an automated message: 
This bug should be fixed in oVirt 3.5.1 RC1, moving to QA

Comment 17 Sandro Bonazzola 2015-01-21 16:03:37 UTC
oVirt 3.5.1 has been released. If problems still persist, please make note of it in this bug report.

Comment 18 Yedidyah Bar David 2016-04-04 11:52:32 UTC
*** Bug 1316973 has been marked as a duplicate of this bug. ***


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