Red Hat Bugzilla – Bug 1024028
[RFE] [dwh] add trigger to stop etl connection via engine db value.
Last modified: 2016-04-04 07:52:32 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):
Please base your work on patch:
That adds the dwh disconnection flag.
At upgrade start change the value to '1' with this commmend:
SET var_value = '1'
WHERE var_name = 'DisconnectDWH';
And at the end please change it back to '0' using:
SET var_value = '0'
WHERE var_name = 'DisconnectDWH';
Do you require any more info?
I thought barak wanted to put it in vdc_options...
Anyway... we need 3 state...
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)
(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
Update on this:
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.
this is required only when we are to split dwh to different host, hence not for 3.4.
(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.
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)
pushing to target release 3.5, assuming its not planned for 3.4 at this point...
Very important due to dwh and engine separation in 3.5.0.
Wouldn't it be better to (also) use listen/notify ?
IIRC we already discussed this (Yaniv and me), not sure what was the conclusion.
(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
I see that the 3.4 clone is closed. Is there anything else needed for 3.5?
(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.
This will also be relevant for RFE Bug 1136726.
This is an automated message:
This bug should be fixed in oVirt 3.5.1 RC1, moving to QA
oVirt 3.5.1 has been released. If problems still persist, please make note of it in this bug report.
*** Bug 1316973 has been marked as a duplicate of this bug. ***