| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-placement - 2019-04-17 | |||
| 20:36:21 | prometheanfire | 2019-04-17 15:35:15.376 6402 ERROR placement sqlalchemy.exc.InvalidRequestError: This Session's transaction has been rolled back due to a previous exception during flush. To begin a new transaction with this Session, first issue Session.rollback(). Original exception was: (psycopg2.IntegrityError) duplicate key value violates unique constraint "traits_pkey" | |
| 20:37:10 | mriedem | ok same as before | |
| 20:37:14 | mriedem | wtf | |
| 20:37:47 | mriedem | the sqla docs say we could set return_defaults=True to insert them one at a time | |
| 20:37:49 | mriedem | maybe that's worth a try | |
| 20:37:57 | mriedem | at the expense of performance | |
| 20:38:03 | mriedem | but it also says, " If the rows to be inserted only refer to a single table, then there is no reason this flag should be set as the returned default information is not used." | |
| 20:38:38 | mriedem | idk, need help from jaypipes and/or zzzeek here | |
| 20:39:25 | mriedem | https://stackoverflow.com/questions/15834569/how-to-bulk-insert-only-new-rows-in-postresql doesn't help me | |
| 20:39:38 | prometheanfire | I tried inserting just one and had the error | |
| 20:39:44 | prometheanfire | see https://gist.github.com/prometheanfire/ff494588ad06fc9c2f55c30524b23478 | |
| 20:40:33 | mriedem | seems like the autoincrement isn't being honored at all | |
| 20:42:05 | prometheanfire | here's the table schema https://gist.githubusercontent.com/prometheanfire/fa71a3c093dc5f1d25ca00fc60238a93/raw/e0ebbdce6b56ca728a9a1e433d47dfc335c29a58/gistfile1.txt | |
| 20:42:31 | melwitt | are these inserts with explicit id? googled and found this https://stackoverflow.com/questions/9108833/postgres-autoincrement-not-updated-on-explicit-id-inserts | |
| 20:42:51 | mriedem | no | |
| 20:43:14 | mriedem | just bulk inserting records with the name and assuming the db will autogenerate/increment the id pkey | |
| 20:43:34 | melwitt | hm | |
| 20:43:55 | mriedem | prometheanfire: what version of sqla do you have? | |
| 20:44:08 | prometheanfire | whatever is in upperconstraints | |
| 20:44:14 | prometheanfire | 1.2.18 | |
| 20:45:31 | zzzeek | mriedem: "autoincerment" in postgresql comes from a sequence object that is independent of the table itself | |
| 20:45:40 | zzzeek | mriedem: so if the table has rows that were hand-inserted into it using ids that the sequence has not addressed yet, "autoincrement" inserts can fail unless the sequence is bumped manually | |
| 20:45:52 | prometheanfire | that's why then | |
| 20:46:13 | prometheanfire | since I did the manual table import (didn't see the migrate script for postgres) | |
| 20:46:43 | zzzeek | prometheanfire: so you need to find the sequences in quesstion and do ALTER SEQUENCE | |
| 20:46:46 | zzzeek | to bump them up | |
| 20:47:46 | prometheanfire | ok, will after reqs meeting is done | |
| 20:47:46 | mriedem | prometheanfire: ah... | |
| 20:47:53 | prometheanfire | mriedem: yep | |
| 20:49:37 | mriedem | we should maybe document a known issue in https://docs.openstack.org/placement/latest/upgrade/to-stein.html | |
| 20:49:53 | mriedem | in case others miss the pg script - or maybe the pg script is missing something | |
| 20:50:57 | prometheanfire | it may be missing something, as it imports the table and does not strip the ID | |
| 20:51:04 | prometheanfire | at least when I read it | |
| 20:51:43 | mriedem | hmm, we have a grenade postgresql job but i think it's in the experimental queue, maybe that's hitting this in stable/stein as well | |
| 20:52:27 | prometheanfire | same might happen in other tables with sequences (user, tec) | |
| 21:00:02 | prometheanfire | looks like that fixed it | |
| 21:00:02 | mriedem | prometheanfire: probably a good idea to report a bug just so it's tracked if someone else hits it (windriver uses postgresql i think, as does huawei...) | |
| 21:00:24 | mriedem | https://storyboard.openstack.org/#!/project/1113 | |
| 21:00:45 | prometheanfire | I will | |
| 21:06:41 | openstackgerrit | Matt Riedemann proposed openstack/placement stable/stein: DNM: log trait sync duplicate entry failure https://review.openstack.org/653585 | |
| 21:08:34 | mriedem | testing grenade-postgresql in stein here https://review.openstack.org/#/c/653587/ | |
| 21:10:55 | prometheanfire | https://storyboard.openstack.org/#!/story/2005478 | |
| 21:10:59 | prometheanfire | thanks | |
| #openstack-placement - 2019-04-18 | |||
| 04:26:27 | openstackgerrit | Tetsuro Nakamura proposed openstack/osc-placement master: Expose version error message generically https://review.openstack.org/653285 | |
| 07:10:16 | openstackgerrit | Tetsuro Nakamura proposed openstack/osc-placement master: Expose version error message generically https://review.openstack.org/653285 | |
| 11:39:00 | openstackgerrit | Chris Dent proposed openstack/placement master: Add links to storyboard worklists to contributing.rst https://review.openstack.org/653719 | |
| 14:14:27 | cdent | prometheanfire, edleafe, mriedem Did you reach any conclusions on the traits stuff? I left some comments on the story that got created, but it's not clear what the proper next step is. | |
| 14:14:56 | edleafe | cdent: it was a bug in PostgreSQL's autoincrement | |
| 14:15:34 | edleafe | If you add IDs to the table manually, Postgres doesn't know that, and just follows its own sequence | |
| 14:17:25 | cdent | edleafe: and presumably this isn't a problem in the postgresql-migrate-db.sh script because it is doing a pg_dump which gets the sequence thingie? | |
| 14:17:38 | edleafe | not sure about that | |
| 14:17:43 | cdent | so how do we make sure it doesn't happen again? | |
| 14:19:01 | mriedem | prometheanfire created a bug in sb | |
| 14:19:09 | mriedem | he didn't use the pg migration script b/c he didn't know it existed | |
| 14:19:17 | edleafe | cdent: you can see the discussion at https://ircsearch.leafe.com/timeline/%23openstack-placement/2019-04-17T20:36:21 | |
| 14:19:28 | mriedem | so there might be a docs opportunity to highlight it in the 'upgrade from nova thing' | |
| 14:19:38 | edleafe | zzzeek confirmed the behavior | |
| 14:19:58 | mriedem | cdent: https://storyboard.openstack.org/#!/story/2005478 | |
| 14:20:04 | cdent | yeah, saw the bug, read the quoted irc on one of mriedem's experiments, added it to the story | |
| 14:20:14 | cdent | just trying to figure out the actual thing to do | |
| 14:20:24 | mriedem | i haven't checked the results of my test | |
| 14:50:48 | cdent | mriedem, efried: not that it seems like anything would, but if anything comes up next week that requires placement ptl-ness, can one of you handle it or make it wait until the week following? | |
| 14:50:58 | efried | sure thing | |
| 14:51:02 | cdent | thanks | |
| 18:01:11 | cdent | https://review.openstack.org/#/c/653719/ which just needs a docs check has been in zuul for 6 hour 20 min. I feel like I should donate some hardware but I have none. | |
| 18:02:12 | efried | cdent: I've noticed the gate being very backlogged of late. Good news is, the spurious failure rate seems *relatively* low. | |
| 18:30:56 | mriedem | blech i wish the table formatting would be fixed http://logs.openstack.org/19/653719/1/check/openstack-tox-docs/9192ba1/html/contributor/contributing.html#storyboard | |
| 18:31:03 | mriedem | i know it's not your fault though | |
| 18:32:54 | efried | mriedem: you mean the fact that there's no borders? | |
| 18:33:49 | mriedem | https://bugs.launchpad.net/openstack-doc-tools/+bug/1825410 | |
| 18:33:50 | openstack | Launchpad bug 1825410 in openstack-doc-tools "table formatting does not have grid lines anymore" [Undecided,New] | |
| 18:33:52 | mriedem | yeah | |
| 18:34:59 | efried | I was talking to johnsom about that last week. He was able to "fix" it in one spot https://review.openstack.org/#/c/652171/ and I was going to see if I could figure out how to make that stick in our projects too. | |
| 18:35:05 | efried | but probably better to fix it in the theme. | |
| 18:36:36 | mriedem | i'm harassing docs people in -dev | |
| 18:46:25 | efried | interestingly, when I build it locally, the table has a border. | |
| 18:47:29 | melwitt | tables without borders | |
| 18:47:41 | efried | aha | |
| 18:47:50 | efried | sphinx version makes the difference. | |
| 18:48:07 | efried | at 1.8.4, borders are there. At 2.0.1, gone. | |
| 19:00:17 | mriedem | prometheanfire: grenade-postgresql in stable/stein (upgrade from rocky to extracted placement) was ok https://review.openstack.org/#/c/653587/ | |
| 19:00:29 | mriedem | no errors on the duplicate entry in the placement api when syncing traits, | |
| 19:00:38 | mriedem | and nova-compute on the stein side was able to report the new traits from stein | |
| 19:00:56 | mriedem | grenade uses postgresql-migrate-db.sh so i'm guessing that's where you went wrong - by not using it | |
| 19:10:32 | mriedem | i'll post a docs patch to hopefully clarify | |
| 19:14:44 | openstackgerrit | Matt Riedemann proposed openstack/placement master: Remind people to use postgresql-migrate-db.sh when migrating data https://review.openstack.org/653833 | |
| 19:31:23 | prometheanfire | mriedem: ya, saw it | |
| 19:32:21 | prometheanfire | mriedem: I need to look through the tables and see if the other auto-incriment stuff needs fixing (probably does) | |
| #openstack-placement - 2019-04-19 | |||
| 00:24:44 | prometheanfire | mriedem: for the tables with id sequences | |
| 00:24:46 | prometheanfire | SELECT setval('users_id_seq', (select max(id) + 1 from users where id is not NULL), FALSE); | |
| 00:25:13 | prometheanfire | max id will probably still work without the is not null, but paranoid | |
| 00:47:54 | openstackgerrit | Merged openstack/placement master: Add links to storyboard worklists to contributing.rst https://review.openstack.org/653719 | |
| 13:30:12 | edleafe | So quiet today... | |
| 13:35:14 | fried_rice | apparently some rabbit hid some eggs | |
| 13:42:08 | edleafe | All this fertility imagery is disturbing | |
| 18:58:38 | mriedem | prometheanfire: is extracted placement packaged for gentoo now? i'm assuming yes. | |
| 19:11:31 | mnaser | mriedem: regarding placement extract stuff and tripleo, I saw Emilien this week at a meetup and asked him, and they haven't made progress on that afaik, I think the patch to use extracted placement was in merge conflict | |
| 19:12:27 | mriedem | hmm, i thought they were deploying fresh installs with extracted placement | |
| 19:12:49 | mriedem | lyarwood is out today and gerrit is down so i can't poke | |
| 19:22:02 | prometheanfire | mriedem: it is | |