Bug 1024028

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

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)

(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

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

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.


Yaniv

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

(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

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. ***