| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-16 | |||
| 18:11:10 | imacdonn | mriedem: I haz the dumb ... how would this solve the problem? | |
| 18:12:01 | mriedem | we don't hit the problem code if you're using neutron | |
| 18:12:17 | imacdonn | but .. I am using neutron, and I do hit the prpblem | |
| 18:12:25 | mriedem | with this patch | |
| 18:12:26 | mriedem | ? | |
| 18:12:48 | imacdonn | no, but the patch only makes a difference if you're not using neutron | |
| 18:12:51 | imacdonn | (?) | |
| 18:13:03 | mriedem | if not NEUTRON: create default sec group | |
| 18:13:14 | imacdonn | oh wait, I had it upside-down | |
| 18:14:35 | imacdonn | yeah OK ... I was about to propose making _security_group_ensure_default() return None if the context has no project_id (which does make the migration work for me) | |
| 18:16:31 | imacdonn | wonder if the migration hits https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L1740 | |
| 18:19:01 | imacdonn | mriedem: ^ I think it will | |
| 18:22:09 | imacdonn | mriedem: confirmed that I still hit the problem with your change, for above reason | |
| 18:24:50 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Do not create default security group during instance create if using Neutron https://review.openstack.org/653065 | |
| 18:24:52 | mriedem | try this ^ | |
| 18:28:18 | imacdonn | mriedem: that seems to work (at least allow the migration to work) | |
| 18:35:25 | mriedem | i still don't know how to recreate your issue | |
| 18:35:51 | imacdonn | you'd have to delete the marker instance (the one with uuid 00000000-0000-0000-0000-000000000000) | |
| 18:36:10 | mriedem | ok so like, | |
| 18:36:16 | mriedem | 1. run data migration, | |
| 18:36:26 | mriedem | 2. archive/purge deleted records | |
| 18:36:29 | mriedem | 3. run data migration | |
| 18:36:54 | imacdonn | I think you have to have at least one project with at least one instance | |
| 18:37:25 | imacdonn | (that's not deleted, I assume) | |
| 18:42:43 | aspiers | efried: haven't been following the channel but I'm around for the next few hours in case you get to reviewing the SEV spec | |
| 18:43:14 | efried | aspiers: ack | |
| 18:44:22 | imacdonn | mriedem: I'm not sure of the exact sequence that gets me into the bad state to begin with, but it has happened repeatedly (after both upgrade and fresh install) ... to force it, you may have to (delete marker instance, run the migration) twice | |
| 18:45:50 | mriedem | on a fresh install you wouldn't have any instances to migrate so i'm not sure how the marker is getting created | |
| 18:46:13 | mriedem | unless you mean: 1. create a test server, 2. run the migration, 3. delete the marker record 4. run the migration again | |
| 18:48:19 | imacdonn | mriedem: by fresh install, I mean that it was not an upgrade ... so like 1) install, 2) create a test instance ... some time later; 3) run the migration | |
| 18:48:39 | mriedem | yeah ok | |
| 18:54:21 | melwitt | random question: does a cold migration (no change in flavor) resize need to be resize confirmed like a flavor changing resize does? | |
| 18:55:26 | mriedem | yes | |
| 18:55:37 | imacdonn | Last time I tried, it was required... whether or not it *should* ...... | |
| 18:56:05 | melwitt | thanks y'all | |
| 19:09:35 | mriedem | imacdonn: well i'm unable to recreate your issue in a functional test but i found a new regression, 500 in the api | |
| 19:18:04 | cdent | mriedem: you're so good at that | |
| 19:20:13 | imacdonn | mriedem: hmm, I was just pondering if maybe the marker instance gets deleted when the last "real" instance for a project is deleted ... in testing that, I just got a "ClientException: Unknown Error (HTTP 504)" - not sure if related | |
| 19:20:21 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add regression test for bug 1825034 https://review.openstack.org/653098 | |
| 19:20:22 | mriedem | imacdonn: would be interested to know why my recreate steps for *your* bug don't hit here ^ | |
| 19:20:22 | openstack | bug 1825034 in OpenStack Compute (nova) "listing deleted servers from the API fails after running fill_virtual_interface_list online data migration" [High,Confirmed] https://launchpad.net/bugs/1825034 | |
| 19:21:27 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add regression test for bug 1825034 https://review.openstack.org/653098 | |
| 19:21:28 | openstack | bug 1825034 in OpenStack Compute (nova) "listing deleted servers from the API fails after running fill_virtual_interface_list online data migration" [High,Confirmed] https://launchpad.net/bugs/1825034 | |
| 19:21:56 | mriedem | imacdonn: the marker instance is soft deleted as soon as it's created | |
| 19:22:27 | mriedem | https://github.com/openstack/nova/blob/master/nova/objects/virtual_interface.py#L308 | |
| 19:23:25 | imacdonn | mriedem: ah, right, so it probably requires archival to have happened to reproduce my original problem | |
| 19:23:35 | mriedem | that's what my functional test does | |
| 19:23:39 | mriedem | but it doesn't hit your issue | |
| 19:24:10 | imacdonn | does it create the two null rows in security_groups ? | |
| 19:24:25 | gmann | looking for review on these 2 specs - https://review.openstack.org/#/c/603969/ https://review.openstack.org/#/c/547850/ | |
| 19:24:48 | gmann | mriedem: would you like to give second round review on this (API cleanup) - https://review.openstack.org/#/c/603969 | |
| 19:24:49 | mriedem | imacdonn: that i don't know - this is also sqlite so i'm not sure if sqlite is more strict about null values in constraints than mysql (that would be funny if it is) | |
| 19:25:15 | mriedem | gmann: it's in the queue somewhere | |
| 19:25:36 | gmann | ok, thanks | |
| 19:26:47 | imacdonn | mriedem: I wouldn't be surprised if sqlite observes null when checking for unique constraint (which we already established that mysql does not) | |
| 19:29:08 | imacdonn | mriedem: OTOH https://sqlite.org/faq.html#q26 seems to suggest otherwise | |
| 19:31:49 | mriedem | imacdonn: i added this to the test and the test passes http://paste.openstack.org/show/749386/ | |
| 19:33:50 | imacdonn | mriedem: is this test running with the admin context ? | |
| 19:34:09 | imacdonn | mriedem: i.e. the one that has no project_id | |
| 19:34:25 | mriedem | ctxt.project_id is an admin context with no project_id, | |
| 19:34:31 | mriedem | self.api.project_id is a non-null value | |
| 19:35:46 | melwitt | gmann: those are in my queue too | |
| 19:39:16 | gmann | melwitt: thanks. | |
| 19:39:41 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add post-test wrinkle to list deleted servers before archive https://review.openstack.org/653131 | |
| 19:44:55 | imacdonn | mriedem: FWIW, I can reproduce my original problem with this sequence: 1) create an instance 2) run migrations 3) archive 4) run migrations | |
| 19:46:01 | mriedem | imacdonn: that's what my functional test does though | |
| 19:46:07 | mriedem | but let me try in devstack | |
| 19:46:19 | mriedem | the neutron fixture in the functional test is likely not creating any virtual interface records | |
| 19:46:21 | imacdonn | mriedem: yeah, except sqlite vs. mysql .... or .... ? | |
| 19:46:26 | mriedem | sure | |
| 19:46:29 | mriedem | i'll spin up a devstack | |
| 19:46:51 | mriedem | also need to get up and stretch the legs and get some coffee | |
| 19:48:29 | mriedem | sean-k-mooney: dansmith: btw that mitaka->newton regression mentioned yesterday is a thing, i reported a bug https://bugs.launchpad.net/nova/+bug/1825018 | |
| 19:48:30 | openstack | Launchpad bug 1825018 in OpenStack Compute (nova) "security group driver gets loaded way too much in the api" [Low,Triaged] | |
| 20:28:26 | mnaser | mriedem: backporting fixed it cleanly. | |
| 20:28:54 | mnaser | I have an abandoned backport if anyone wants to cherry pick cause it applies cleanly right now | |
| 20:29:33 | mnaser | Left a comment too so if someone finds the bug and sees the proposed but then abandoned patch, they’ll see some useful info there | |
| 20:30:01 | openstackgerrit | melanie witt proposed openstack/nova master: Count instances from mappings and cores/ram from placement https://review.openstack.org/638073 | |
| 20:30:01 | openstackgerrit | melanie witt proposed openstack/nova master: Add get_counts() to InstanceMappingList https://review.openstack.org/638072 | |
| 20:30:02 | openstackgerrit | melanie witt proposed openstack/nova master: Add get_usages_counts_for_quota to SchedulerReportClient https://review.openstack.org/653145 | |
| 20:30:02 | openstackgerrit | melanie witt proposed openstack/nova master: Use instance mappings to count server group members https://review.openstack.org/638324 | |
| 20:30:03 | openstackgerrit | melanie witt proposed openstack/nova master: Set [quota]count_usage_from_placement = True in nova-next https://review.openstack.org/653146 | |
| 20:30:16 | mriedem | mnaser: ah so the heal task fixed up the network info cache? | |
| 20:30:20 | mriedem | on that rocky cloud | |
| 20:30:35 | mnaser | Yep. Just watched them slowly get repopulated | |
| 20:30:39 | mriedem | nice | |
| 20:30:45 | mnaser | Had to apply on all computes tho which was annoying but yeah | |
| 20:31:01 | mriedem | btw, another reason to not backport that data migration, i just found this https://bugs.launchpad.net/nova/+bug/1824435 | |
| 20:31:03 | openstack | Launchpad bug 1824435 in OpenStack Compute (nova) stein "fill_virtual_interface_list migration fails on second attempt" [High,Triaged] | |
| 20:31:05 | mnaser | I probably will redeploy again without it.. if they disappear again.. will raise question | |
| 20:31:17 | mnaser | Yeah I saw that too as well. Never ran into that though.. yet :X | |
| 20:31:46 | mriedem | mnaser: run this as admin on your stein cloud: openstack server list --all-projects --deleted | |
| 20:32:17 | mnaser | o should I be worried about that | |
| 20:32:25 | mriedem | running the command or the bug? | |
| 20:32:34 | mnaser | The command | |
| 20:32:38 | mriedem | it's read-only | |
| 20:32:46 | mnaser | As in is there some magical bug we’re about to discover | |
| 20:32:59 | mriedem | heh i've already discovered the bug | |
| 20:33:01 | mriedem | i think you already have it | |
| 20:33:18 | mnaser | But I can do that later, I also can do it both on a cloud that has db archive enabled and disabled too | |