Earlier  
Posted Nick Remark
#openstack-nova - 2019-04-16
17:26:53 openstackgerrit Stephen Finucane proposed openstack/nova master: Stop handling 'update_cells' on 'BandwidthUsage.create' https://review.openstack.org/651303
17:26:54 openstackgerrit Stephen Finucane proposed openstack/nova master: Stop handling 'InstanceUnknownCell' exception https://review.openstack.org/651307
17:26:54 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove cells code https://review.openstack.org/651306
17:26:55 openstackgerrit Stephen Finucane proposed openstack/nova master: db: Remove cell APIs https://review.openstack.org/651309
17:26:55 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove unnecessary wrapper https://review.openstack.org/651308
17:27:08 mriedem dansmith: replied but yeah i think so
17:27:59 dansmith cool
17:28:42 sean-k-mooney mriedem: so related but sperate form gibis spec should we jsut use teh livemigration multiple port bindign workflow for all move operations
17:29:04 sean-k-mooney mriedem: i mentioned it in gibi's spec but it would simplfy things to have a singel common code path
17:29:53 mriedem given the issues NewBruce is hitting idk
17:30:36 mriedem moving all move operations to that model would be a big change i think, and likely not something we should block gibi's spec on
17:30:53 sean-k-mooney oh im not suggesting we should block on it
17:31:11 sean-k-mooney its jsut some/alot of the compleix would be reduced
17:31:37 sean-k-mooney but NewBruce issue is concering ill grant that
17:35:28 francoisp_ alex_xu, hi, would you have time to look at https://review.openstack.org/#/c/648123/6 - thanks!
18:05:11 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:05:12 mriedem imacdonn: let's see what blows up ^
18:09:19 imacdonn mriedem: hmm .. wouldn't use_neutron be true in most cases, when the migration is being run ?
18:10:37 mriedem yes use_neutron is the default and what 99% of deployments are probably using at this point
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

Earlier   Later