@gnaponie and I are currently working on deploying a new version of Waiverdb (initially just in stage, before we go to prod). This deployment includes a database migration step, which runs as a pre-deployment hook in Openshift, to change how waivers are stored in the database.
For each row, the migration script expects the result_id to refer to a result in the Resultsdb database. In prod this should certainly be true (and if it's not, we have some data to fix before the deployment will proceed). However in stage Waiverdb, there is just one waiver, and it is a nonsensical one left by @ralph for testing purposes. :-) That one waiver in stage Waiverdb unfortunately refers to result_id 123 which doesn't exist in stage Resultsdb, causing the migration to bail out.
result_id
Waivers are supposed to be immutable, so the API does not permit modifying or deleting the rows. But since there is just this one row, and the data is not real, we think the simplest solution to get the migration going is just to UPDATE the database directly to make the row refer to a real result_id.
Since Giulia and I do not have any direct access to the Postgres database for waiverdb, can you please help us to fix up the offending row so that the migration can be completed?
On db01.stg.phx2.fedoraproject.org, waiverdb database, please run:
UPDATE waiver SET result_id = 10349830 WHERE id = 9;
There are 9 results, all pointing to result_id 123, are you sure you want to only change the 9th one? Not the other 8?
123
Yeah, it should be all of them (with the 123 value).
Metadata Update from @ralph: - Issue assigned to ralph
on it
Metadata Update from @pingou: - Assignee reset
Done :)
Metadata Update from @pingou: - Issue close_status updated to: Fixed
You beat me to it!
Metadata Update from @ralph: - Issue status updated to: Open (was: Closed)
waiverdb=# select * from waiver; id | result_id | username | product_version | waived | comment | timestamp | proxied_by | subject | testcase ----+-----------+----------+-----------------+--------+---------------+----------------------------+------------+---------+---------- 1 | 10349830 | ralph | fedora-26 | t | This is fine. | 2017-11-06 21:24:13.614576 | | | 2 | 10349830 | ralph | fedora-26 | t | This is fine. | 2017-11-06 21:42:57.263012 | | | 3 | 10349830 | ralph | fedora-26 | t | This is fine. | 2017-11-06 22:03:12.960449 | | | 4 | 10349830 | ralph | fedora-26 | t | This is fine. | 2017-11-06 22:08:39.181011 | | | 5 | 10349830 | ralph | fedora-26 | t | This is fine. | 2017-11-07 01:44:24.98007 | | | 6 | 10349830 | ralph | fedora-26 | t | This is fine. | 2017-11-07 01:44:38.110845 | | | 7 | 10349830 | ralph | fedora-26 | t | This is fine. | 2017-11-07 02:10:17.808641 | | | 8 | 10349830 | ralph | fedora-26 | t | This is fine. | 2017-11-07 02:13:30.466388 | | | 9 | 10349830 | ralph | fedora-26 | t | This is fine. | 2017-11-07 22:45:23.145888 | | | (9 rows)
FYI, here is the content of prod:
waiverdb=# select * from waiver; id | result_id | username | product_version | waived | comment | timestamp | proxied_by ----+-----------+----------------+-----------------+--------+-----------------------------------------+----------------------------+------------ 1 | 18974991 | ralph | fedora-27 | t | This is fine. | 2018-01-23 18:02:04.630122 | 2 | 18858203 | ellert | fedora-26 | t | Template instantiation | 2018-01-23 18:10:39.475537 | 3 | 18858203 | ellert | fedora-26 | t | Template instantiation | 2018-01-23 18:12:33.018331 | 4 | 18791098 | rdossant | fedora-26 | t | Version bump, abi changes are expected | 2018-01-23 18:29:17.856056 | 5 | 18858203 | ellert | fedora-26 | t | Template instantiation | 2018-01-23 19:00:15.462032 | 6 | 18790139 | rdossant | fedora-27 | t | Version bump, abi changes are expected | 2018-01-24 16:02:25.048106 | 7 | 18790165 | rdossant | fedora-27 | t | Just warnings | 2018-01-24 16:04:25.951993 | 8 | 19127454 | ignatenkobrain | fedora-27 | t | This is fine. | 2018-01-31 13:35:02.236998 | 9 | 19127454 | ignatenkobrain | fedora-27 | t | Those 2 symbols were public incorrectly | 2018-01-31 13:35:46.080399 | 10 | 19700975 | dshea | fedora-27 | t | Erroneous multilib failure | 2018-02-13 21:22:08.932174 | 11 | 19700975 | dshea | fedora-27 | t | Invalid result from rpmdeplint | 2018-02-13 22:30:30.155179 | 12 | 19679113 | alexpl | fedora-27 | t | This is fine. | 2018-02-20 07:32:25.559635 | 13 | 19678515 | alexpl | fedora-27 | t | This is fine. | 2018-02-20 07:33:47.510933 | 14 | 19678515 | alexpl | fedora-26 | t | This is fine. | 2018-02-20 12:38:16.664326 | 15 | 19677525 | alexpl | fedora-26 | t | This is fine. | 2018-02-20 12:41:55.208346 | 16 | 19676827 | alexpl | fedora-26 | t | This is fine. | 2018-02-20 12:42:23.753557 | 17 | 19676338 | alexpl | fedora-26 | t | This is fine. | 2018-02-20 12:44:35.659582 | 18 | 19674737 | alexpl | fedora-26 | t | This is fine. | 2018-02-20 12:44:55.557884 | 19 | 19673733 | alexpl | fedora-26 | t | This is fine. | 2018-02-20 12:45:21.161827 | 20 | 19673017 | alexpl | fedora-26 | t | This is fine. | 2018-02-20 12:48:12.562255 | 21 | 19672797 | alexpl | fedora-26 | t | This is fine. | 2018-02-20 12:48:44.130646 | 22 | 19671845 | alexpl | fedora-26 | t | This is fine. | 2018-02-20 12:49:00.100087 | 23 | 19671455 | alexpl | fedora-26 | t | This is fine. | 2018-02-20 12:49:20.261893 | 24 | 19678515 | alexpl | fedora-26 | t | This is fine. | 2018-02-20 15:35:47.814537 | 25 | 19816117 | nphilipp | fedora-27 | t | This is an intentional constness fix. | 2018-02-20 22:22:43.966819 | 26 | 19816144 | nphilipp | fedora-26 | t | This is an intentional constness fix. | 2018-02-20 22:23:22.241304 |
Metadata Update from @ralph: - Issue status updated to: Closed (was: Open)
Oh yeah, I only saw one coming back from the API but I forgot that it would not return obsoleted waivers for the same result_id. So I didn't realise there would be other rows in there.
Thanks for the help everyone! I see that the Waiverdb stg migration has succeeded now and it's up and running.
Login to comment on this ticket.