Bug 1024028 - [RFE] [dwh] add trigger to stop etl connection via engine db value.
[RFE] [dwh] add trigger to stop etl connection via engine db value.
Status: CLOSED CURRENTRELEASE
Product: oVirt
Classification: Community
Component: ovirt-engine-core (Show other bugs)
3.4
x86_64 Linux
high Severity high
: ---
: 3.5.1
Assigned To: Yedidyah Bar David
Pavel Stehlik
integration
: FutureFeature
Depends On: 1023754
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-28 11:55 EDT by Yaniv Lavi (Dary)
Modified: 2016-04-04 07:52 EDT (History)
11 users (show)

See Also:
Fixed In Version: ovirt-3.5.1_rc1
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 1023754
Environment:
Last Closed: 2015-01-21 11:03:37 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 20657 None None None Never
oVirt gerrit 34566 master MERGED packaging: setup: Stop remote dwh Never
oVirt gerrit 34817 ovirt-engine-3.5 MERGED packaging: setup: Stop remote dwh Never

  None (edit)
Description Yaniv Lavi (Dary) 2013-10-28 11:55:23 EDT
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 (Dary) 2013-10-29 10:36:14 EDT
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 11:08:14 EDT
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 (Dary) 2013-10-29 12:11:29 EDT
(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 (Dary) 2014-01-12 10:28:08 EST
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 17:10:07 EST
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 04:21:24 EST
(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 04:35:05 EST
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 13:31:22 EST
pushing to target release 3.5, assuming its not planned for 3.4 at this point...
Comment 9 Yaniv Lavi (Dary) 2014-06-12 07:42:04 EDT
Very important due to dwh and engine separation in 3.5.0.


Yaniv
Comment 11 Yedidyah Bar David 2014-07-21 06:04:23 EDT
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 06:59:00 EDT
(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 08:28:54 EDT
I see that the 3.4 clone is closed. Is there anything else needed for 3.5?
Comment 14 Yaniv Lavi (Dary) 2014-08-07 08:32:33 EDT
(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 04:27:01 EDT
This will also be relevant for RFE Bug 1136726.
Comment 16 Sandro Bonazzola 2015-01-15 09:15:27 EST
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 11:03:37 EST
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 07:52:32 EDT
*** 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.