Earlier  
Posted Nick Remark
#openstack-nova - 2019-04-19
14:01:31 mriedem my offer to mail it still stands
14:02:16 fried_rice Then it'll be, "the nickel's in the mail." I've heard that one before too.
14:04:19 fried_rice I get that same NoSuchGroupError in stein and rocky. So I'm guessing there's a bug in the test setup where the test env doesn't run through the code path that registers the options if I'm just running those two tests.
14:05:55 mriedem https://photos.app.goo.gl/giiB1e8RD8WztkaQ8
14:05:57 mriedem i've set a reminder
14:06:23 mriedem fried_rice: yeah i get the same: $ tox -r -e py36 -- nova.tests.unit.test_rpc --until-failure
14:07:38 fried_rice so that's a red herring for our gate failure :(
14:12:12 fried_rice If you actually pay me off, I won't be able to keep giving you crap about it. We need a different plan.
14:14:46 mriedem what i'd like to know is what is calling oslo.config when the death spiral starts
14:23:22 mriedem well i fixed that latent traceback at least :)
14:23:25 fried_rice Running all of py36 locally I got these:
14:23:26 fried_rice {2} nova.tests.unit.pci.test_utils.PciDeviceMatchTestCase.test_spec_extra_key [] ... inprogress
14:23:26 fried_rice {7} nova.tests.unit.objects.test_instance_group.TestInstanceGroupObject.test_get_by_hint [] ... inprogress
14:24:53 fried_rice oh, by the way, that ^ was on rocky
14:25:54 fried_rice what have we backported lately?
14:26:57 mriedem shrug, lots of stuff
14:27:07 mriedem what is getting an option with a namespace? https://github.com/openstack/oslo.config/blob/6.8.1/oslo_config/cfg.py#L2614
14:27:12 mriedem wtf is a config option namespace?
14:27:15 mriedem stephenfin: ^?
14:27:31 mriedem http://logs.openstack.org/45/649345/7/check/openstack-tox-py36/ba15c17/job-output.txt.gz#_2019-04-18_18_10_53_423952
14:27:37 mriedem that's where the stack overflow starts
14:28:24 fried_rice and why am I suddenly getting
14:28:24 fried_rice Error: pg_config executable not found.
14:28:24 fried_rice when rebuilding my venv??
14:28:46 mriedem https://github.com/openstack/oslo.config/blob/6.8.1/oslo_config/cfg.py#L2183
14:29:33 mriedem might be due to newer psycopg2?
14:29:42 mriedem are you on 18.04?
14:29:46 mriedem bionic i mean
14:30:38 fried_rice yes. Have been for three months. Apparently I suddenly needed libpq-dev
14:31:01 fried_rice four months
14:31:05 fried_rice time flies
14:31:46 fried_rice On master I just got
14:31:46 fried_rice {6} nova.tests.unit.objects.test_instance.TestRemoteInstanceObject.test_create_with_extras [] ... inprogress
14:31:46 fried_rice '>' not supported between instances of 'NoneType' and 'datetime.datetime'
14:31:58 fried_rice so it's not RPC I guess
14:32:40 mriedem heh i can't recreate oslo_config.cfg.NoSuchGroupError: no such group [oslo_messaging_notifications] now
14:32:51 yan0s So, novnc produces the error I mentioned earlier when both a key pair and a cloud-config (setting user password) are set
14:33:12 mriedem fried_rice: that's what i saw yesterday when looking at this
14:33:33 mriedem it's not in the logs everytime the stack overflow happens, but i know the cells 1 removal stuff touched some of that code
14:55:08 openstackgerrit Matt Riedemann proposed openstack/nova master: Only set oslo_messaging_notifications.driver if using RPCFixture https://review.openstack.org/653954
15:43:28 kashyap Hmm, https://review.openstack.org/ is offline
15:44:20 dansmith kashyap: see topic
15:45:45 kashyap dansmith: Yeah, noticed it. _Just_ when I was hitting send on a comment I saw it go down
15:46:10 kashyap dansmith: But, I trained my muscle memory to copy it into an editor; before pasting it :-)
15:46:15 kashyap dansmith: Shouldn't you be offline, too?
15:46:46 dansmith no :)
15:46:58 dansmith this day has no special meaning for me
15:47:17 kashyap Hehe, nod.
15:48:33 edleafe It *is* the 244th anniversary of the start of the American Revolution. Surely *that* has meaning for you?
16:00:57 mriedem weeeee https://bugs.launchpad.net/nova/+bug/1825537
16:00:59 openstack Launchpad bug 1825537 in OpenStack Compute (nova) "finish_resize failures incorrectly revert allocations" [Medium,Triaged]
16:01:12 mriedem mnaser: eandersson: ^ will add to the placement allocations are wrong woes
16:01:34 mriedem i've got a recreate test locally which i'll push up once gerrit is back
16:11:11 mriedem dansmith: interested in your opinion on the options i've laid out in https://bugs.launchpad.net/nova/+bug/1825537 for fixing it - comment 2
16:11:12 openstack Launchpad bug 1825537 in OpenStack Compute (nova) "finish_resize failures incorrectly revert allocations" [Medium,Triaged]
16:11:57 dansmith mriedem: this is getting really old
16:12:04 dansmith can't you do something positive to help the project?
16:12:22 mriedem would you like auto-formatted code style?
16:12:33 mriedem it will bring the new contribs
16:12:57 dansmith yes please!
16:13:48 dansmith mriedem: I'm highly allergic to changing the host/node assignment timing
16:14:08 dansmith not because what we do today is good or right, but just because I'm afraid of breaking tons of other things that encode those assumptuons
16:14:11 dansmith *assumptions
16:14:51 mriedem dansmith: i.e. "I think this is probably not really an option because finish_resize has never done this on failure and we don't really know what state the instance is in"
16:15:09 dansmith sure
16:15:41 mriedem i don't think that's really a good option either, i just listed it for completeness
16:16:46 mriedem an auto-revert is appealing but i very much doubt the revert code is graceful enough to handle it, b/c of baked in assumptions about the state of the world when a revert is started
16:17:14 mriedem e.g. "cleaning up networking...wtf there is no networking on this host KABOOM!!!"
16:22:47 fried_rice mriedem: Did you already do the e-r thing for bug 1825435?
16:22:48 openstack bug 1825435 in OpenStack Compute (nova) "TestRPC unit tests intermittently fail with "'>' not supported between instances of 'NoneType' and 'datetime.datetime'" - maybe due to "Fatal Python error: Cannot recover from stack overflow."" [High,Confirmed] https://launchpad.net/bugs/1825435
16:22:54 mriedem yeah
16:22:58 fried_rice k
16:23:33 mriedem http://status.openstack.org/elastic-recheck/#1825435
16:28:04 mriedem dansmith: ok option 1 fix is quick and easy and already done locally
16:28:08 mriedem it's essentially just doing what confirm_resize does
16:28:12 dansmith cool
18:00:39 eandersson Sweet mriedem_lunch
18:01:02 eandersson fried_rice, We have this in Rocky as well. I don't think it ever worked.
18:01:58 eandersson https://github.com/openstack-dev/devstack/blob/master/lib/nova_plugins/hypervisor-ironic#L44
18:02:13 eandersson We don't add a region_name, so that path was never really tested.
18:43:07 fried_rice eandersson: Okay. It's nearly impossible to test with all the permutations of ksa opts, times all the permutations of service catalog and endpoint setups. Inevitable that we missed things.
18:43:20 eandersson Yep
18:43:36 eandersson For sure.
18:43:47 eandersson I opened a PR to have it added.
18:44:12 fried_rice eandersson: IIUC this is only reproducible when there's a real ironicclient listening on the other end?
18:44:38 eandersson The problem is really that the real ironicclient hides this.
18:44:41 fried_rice right
18:44:50 fried_rice oh
18:44:57 fried_rice wait, you mean the *real* real ironicclient?
18:45:03 eandersson Since when you pass on a None value, the ironicclient tries to figure it out.
18:45:19 eandersson Yep
18:45:35 fried_rice so... where is it a problem?
18:46:09 eandersson Well the problem is that ironicclient is smart, but not smart enough
18:46:22 eandersson when you pass on a None endpoint it just gets the first endpoint in the catalog
18:47:15 eandersson and does not take region into account
18:48:47 eandersson There has been multiple bugs with this code pass, so been difficult to know exactly where things are failing
18:49:12 eandersson e.g. https://github.com/openstack/python-ironicclient/commit/466be3b6568b643605d826e5aa26d9a344cc74ae
18:49:40 eandersson *code path
18:50:48 fried_rice I don't actually see where we're taking region into account at all.
18:51:04 eandersson Yea - that was my first assumption.

Earlier   Later