3:28 a.m.
Hello both of you,
thanks for your detailed explainations and support, still thinking which
way i will go. tending to try the dirty way in a lab setup before to see
what happens.
Will post updates when i got more :)
Cheers,
Juergen
>>>>> It seems that somebody had deleted manually the
constraint
>>>>> fk_event_subscriber_event_notification_methods from your database
>>>>> Therefor, the first line that attempts to drop this constraint in
>>>>> 03_05_0050_event_notification_methods.sql: ALTER TABLE
event_subscriber
>>>>> DROP CONSTRAINT fk_event_subscriber_event_notification_methods;
>>>>> fails.
>>>>
>>>> uhm, interesting. could this be caused be deinstallation of dwh
>>>> reporting?
>>
>> How exactly did you do that?
>
>
> very good question, thats a few months ago. i whould guess with rpm -e
> before an engine upgrade (if i remember correctly there was one ovirt
> release where dwh was missing for el6).
>
>>
>> Note that partial cleanup is not supported yet [1].
>
> checking right after that mail :)
>
>>
>> Can you please post all of /var/log/ovirt-engine/setup/* ?
>
> sure, sending you the dl link in a private mail. since i am not sure if
> i sed´ed out all "private" things
Based on these logs, it seems to me that:
1. At some point you upgraded to a snapshot of master (then-3.4), installing
ovirt-engine-3.4.0-0.12.master.20140228075627.el6.
2. This package had an older version of the script
dbscripts/upgrade/03_04_0600_event_notification_methods.sql .
3. Therefore, when you now try to upgrade, engine-setup tries to run the
newer version, and fails. Why? Because it keeps in the database the checksum
of every upgrade script it runs, and does not run again scripts with same
checksum. But in your case the checksums are different, so it does try that.
It fails, because the older version already dropped the table
event_notification_methods.
How to fix this?
First, note that upgrades between dev/beta/rc/etc versions is not supported.
So the "official" answer is to remove everything and start from scratch. Or, if
you
have good backups of the latest 3.3 version you had, restore to that one and then
upgrade to 3.4 and then 3.5.
If you want to try and force an upgrade, you can do the following, but note that
it might fail elsewhere, or even fail in some future upgrade:
1. Following a 'git log' of this file, it seems to me that the only change it
went through between the version you installed and the one in final 3.4, is [1].
It seems that the relevant part of this change can be done by you by running:
ALTER TABLE event_subscriber ADD COLUMN notification_method CHARACTER VARYING(32) DEFAULT
'EMAIL' CHECK (notification_method IN ('EMAIL', 'SNMP_TRAP'));
2. After you do that, you can convince engine-setup that you already ran the
version of the script you now have, by running:
update schema_version set checksum='feabc7bc7bb7ff749f075be48538c92e' where
version='03040600';
Backup everything before you start.
No guarantee. Use at your own risk.
As I said, better remove everything and setup again clean or restore your
latest backup of a supported version and upgrade from that one.
Good luck. Please report back :-) Thanks,
[1] http://gerrit.ovirt.org/25393