Bug 1330715
Summary: | engine-cleanup failed after corrupt update | ||
---|---|---|---|
Product: | [oVirt] ovirt-engine | Reporter: | gregor <gregor_forum> |
Component: | General | Assignee: | Greg Padgett <gpadgett> |
Status: | CLOSED DEFERRED | QA Contact: | |
Severity: | urgent | Docs Contact: | |
Priority: | unspecified | ||
Version: | 3.6.4.1 | CC: | ahino, amureini, bugs, emesika, gpadgett, gregor_forum, oourfali |
Target Milestone: | --- | Flags: | amureini:
ovirt-3.6.z?
rule-engine: planning_ack? rule-engine: devel_ack? rule-engine: testing_ack? |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-05-09 20:12:27 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
gregor
2016-04-26 18:53:15 UTC
UPDATE: I fixed the permissions of the function 'ovirt_repair_failed_merge' then engine-cleanup did his job. These where my steps: 1. List users and note their id's sudo -u postgres psql engine -c " SELECT u.usename, u.usesysid, CASE WHEN u.usesuper AND u.usecreatedb THEN CAST('superuser, create database' AS pg_catalog.text) WHEN u.usesuper THEN CAST('superuser' AS pg_catalog.text) WHEN u.usecreatedb THEN CAST('create database' AS pg_catalog.text) ELSE CAST('' AS pg_catalog.text) END AS "Attributes" FROM pg_catalog.pg_user u ORDER BY 1; " 2. Check the owner sudo -u postgres psql engine -c " SELECT p.proname, p.proowner FROM pg_catalog.pg_namespace n JOIN pg_catalog.pg_proc p ON p.pronamespace = n.oid WHERE n.nspname = 'public' and p.proname = 'ovirt_repair_failed_merge' " 3. Fix the owner of the function with the right id from the user 'engine' noted from step 1. sudo -u postgres psql engine -c " UPDATE pg_catalog.pg_proc SET proowner = 16384 WHERE proname = 'ovirt_repair_failed_merge' " 4. Check the owner as in step 2. 5. Run engine-cleanup TODO: Restore and re-run the upgrade to check side-effects UPDATE: This fixed the problem and after restore the update worked ;-) Should I close this? I think this can be a bug but its not clear why the permissions of the function 'ovirt_repair_failed_merge' was messed up. (In reply to gregor from comment #2) > UPDATE: This fixed the problem and after restore the update worked ;-) Thanks - this is important information. > > Should I close this? I think this can be a bug but its not clear why the > permissions of the function 'ovirt_repair_failed_merge' was messed up. We'll check it, anything out of ordinary in your setup? Today I updated another host without problems. This host was first installed with something 3.6.*. The problem host was initially installed with something 3.5.* and as an AIO-installation. ovirt_repair_failed_merge is not in the context of engine source nor on engine-setup sources, I wonder which component owns it Seems related to https://bugzilla.redhat.com/show_bug.cgi?id=1302215#c13 (thanks to Didi!) Greg, can you take a look at that, it seems that this new SP can be installed into the database with any legal user which can make problems in engine-cleanup (In reply to Eli Mesika from comment #6) > Seems related to https://bugzilla.redhat.com/show_bug.cgi?id=1302215#c13 > (thanks to Didi!) > > Greg, can you take a look at that, it seems that this new SP can be > installed into the database with any legal user which can make problems in > engine-cleanup Thanks for finding this one. The ovirt_repair_failed_merge is a stored procedure that is part of a temporary workaround for an engine bug in Live Merge; I should have included in the original instructions to remove the SP after use. Consequently, the easiest way to fix this problem would be to simply drop the SP: psql <dbname> -U <dbuser> -c 'DROP FUNCTION ovirt_repair_failed_merge(varchar, varchar, varchar, varchar)' I'll update the other related bugs with this info as well. Based on last comment, moving to Storage. Greg, as this stored procedure is created as a manual workaround, is there anything to actually do here besides update the KBase? (In reply to Allon Mureinik from comment #9) > Greg, as this stored procedure is created as a manual workaround, is there > anything to actually do here besides update the KBase? I don't think so. I confirmed in bug 1308501 that the instructions in the KBase now indicates that the script should be removed after use, and also added that to other bugs mentioning the workaround. I believe we're good here. (Gregor, I'm closing this as notabug--not because it isn't an issue, but because I don't see anything that means "addressed outside the product code". Thanks for finding/reporting it.) (In reply to Greg Padgett from comment #10) > (Gregor, I'm closing this as notabug--not because it isn't an issue, but > because I don't see anything that means "addressed outside the product > code". Thanks for finding/reporting it.) DEFERED kinda-sorta means that. |