Earlier  
Posted Nick Remark
#openstack-nova - 2019-02-15
16:20:43 fried_rice belmoreira: Good thing ProviderTree isn't an ovo :P
16:20:49 leakypipes job done. weekend awaits.
16:21:59 belmoreira fried_rice: is not 5100 compares
16:22:41 tssurya mriedem: thanks a lot! done
16:23:00 fried_rice belmoreira: Based on: 1700 iterations of the loop; each loop is doing three set_*_for_provider()s; and each set_*_for_provider is asking ProviderTree.has_*_changed()
16:23:32 fried_rice (ugh, my IRC client made a mess of that)
16:24:07 fried_rice ohhh
16:24:13 fried_rice So, here's a thing.
16:24:19 fried_rice The roots are stored in a list
16:24:32 fried_rice which we're iterating over to find the one we're asking about
16:24:50 fried_rice O(N) just to find the provider to do the compare on.
16:24:57 fried_rice So O(N^2) for that loop.
16:25:00 fried_rice Times three.
16:25:19 fried_rice belmoreira: You have a way to shove in a patch and test this easily?
16:25:33 tssurya dansmith, mriedem: yes !!! thanks a lot for the reviews on the API changes :) and sorry for giving such a hard time on that series :D but I am seriously happy that's done. I will respin something for the nits
16:25:39 gibi leakypipes, fried_rice: thanks
16:25:53 belmoreira fried_rice: I just did it... in the
16:25:58 mriedem tssurya: no problem, it's a complicated change
16:26:21 mriedem now just figure out how to not grind the API on startup when there is a down cell
16:26:22 mriedem :)
16:26:31 tssurya haha yea
16:27:58 dansmith tssurya: np, thanks for your persistence
16:28:02 belmoreira efried_rice: for the "updated_from_provider_tree" I'm also passing the compute_node and removed the last "for". It only to update/check that resource provider
16:29:15 fried_rice belmoreira: That would be one way to do it.
16:29:24 fried_rice belmoreira: care to push that patch?
16:30:15 fried_rice belmoreira: But I don't think that's a generic solution long-term. I think it's going to break as soon as we have shared storage providers, for example.
16:30:30 fried_rice belmoreira: Let me play with the efficiency of ProviderTree itself and see if I can't get that loop a lot tighter...
16:31:04 belmoreira fried_rice: ohh no! this was emergency mode :) just to keep Ironic alive
16:31:23 fried_rice Code blue, get a crash cart in here, got it.
16:36:12 melwitt le sigh, the ceph job is consistently timing out taking too long to run. not sure what could have changed
16:40:58 fried_rice belmoreira: are you running py2 or py3?
16:41:21 belmoreira fried_rice: py2
16:41:30 fried_rice ight
16:42:40 belmoreira v
16:42:44 melwitt dansmith: your review on the spec amendment for detach boot volume would be appreciated https://review.openstack.org/619161
16:43:10 dansmith melwitt: appreciated how much?
16:43:59 melwitt I have chicago style popcorn
16:44:35 dansmith yeah, alright.
16:45:50 melwitt lol
16:48:55 openstackgerrit Merged openstack/nova master: Make VolumeAttachmentsSampleV249 test other methods https://review.openstack.org/633621
16:49:04 belmoreira I need to leave, thanks for all the help
16:54:04 openstackgerrit Merged openstack/nova-specs master: Amend the detach-boot-volume design https://review.openstack.org/619161
17:00:34 mriedem melwitt: for the same reasons the tempest-full job times out
17:00:49 mriedem http://status.openstack.org/elastic-recheck/#1783405
17:00:55 mriedem https://review.openstack.org/#/q/topic:bug/1783405+(status:open+OR+status:merged)
17:01:10 mriedem {1} tempest.scenario.test_network_advanced_server_ops.TestNetworkAdvancedServerOps.test_server_connectivity_reboot [278.769116s] ... ok
17:01:18 mriedem {1} tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern [231.855718s] ... ok
17:01:27 mriedem {2} tempest.api.compute.volumes.test_attach_volume.AttachVolumeTestJSON.test_attach_detach_volume [224.248984s] ... ok
17:01:51 mriedem {0} tempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario [266.396758s] ... ok
17:02:49 melwitt oh, I see. thank you. I didn't know the test times are on the tests
17:02:51 mriedem actually it would be worse
17:02:58 mriedem because tempest-full skips slow tests
17:03:00 mriedem but the ceph job doesn't
17:03:15 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP Use migration_status during volume migrating and retyping https://review.openstack.org/637224
17:03:18 mriedem and the ceph job is also running cinder tempest plugin tests
17:03:38 melwitt the ceph job does it all!
17:03:41 mriedem http://git.openstack.org/cgit/openstack/devstack-plugin-ceph/tree/.zuul.yaml#n16
17:03:47 mriedem ^ should be increased probably
17:03:53 melwitt it was fine until recently, now it's timing out constantly
17:03:58 openstackgerrit Eric Fried proposed openstack/nova master: WIP: Perf: Use dicts for ProviderTree roots https://review.openstack.org/637225
17:04:18 fried_rice belmoreira, tssurya: ^ try that out, if you please.
17:04:19 mriedem well, skipping slow tests would help quite a bit
17:05:19 mriedem at the sacrifice of coverage
17:05:49 melwitt yeah, that's what I was about to say. a separate ceph slow tests job comes to mind but "yet another job"
17:05:51 mriedem http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n276
17:05:51 mriedem compare to the timeout on the tempest-slow job which only runs slow tests
17:05:55 mriedem that timeout is 3 hours rather than 2
17:06:11 mriedem the easy fix is bumping the timeout
17:06:33 mriedem but if that job is consistently taking over 2 hours, that means all nova changes are waiting at least that long in the check queue for results from a non-voting job
17:07:00 melwitt hm, yeah
17:07:01 mriedem so if we're going to wait that long for that job, i think it needs to be voting
17:07:19 mriedem and if it's going to take that long and be non-voting, i think it's place is in the experimental queue
17:07:31 melwitt yeah, that's fair
17:07:51 mriedem probably something to be brought up in the ML since it likely also affects other projects (cinder/glance at least)
17:08:52 smcginnis ++
17:09:16 melwitt the job was as stable as the normal tempest-full (I need to get the graph again) for quite a while, but I never got around to trying to make it voting again
17:09:36 melwitt yeah, ok. I'll grab the data and post to the ML
17:10:55 mriedem speaking of jobs, it looks like while i fixed legacy-grenade-dsvm-neutron-multinode-live-migration the zuul.yaml change on irrelevant-files means it's not running on nova changes now...
17:11:18 mriedem https://review.openstack.org/#/c/634962/5/.zuul.yaml@242
17:15:16 melwitt ?
17:15:44 mriedem e.g. that job isn't running on https://review.openstack.org/#/c/591657/
17:16:01 mriedem it's now only running if there are changes to nova/tests/live_migration/
17:16:16 melwitt oh.... oops
17:16:55 mriedem nova/tests/live_migration/ should probably move under nova/gate/
17:18:40 melwitt that's weird, I thought we've used that regex before to run on nova/tests/live_migration in addition to non-test nova changes
17:20:34 mriedem i've got a fix
17:25:49 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix irrelevant-files for legacy-grenade-dsvm-neutron-multinode-live-migration https://review.openstack.org/637231
17:29:25 openstackgerrit Balazs Gibizer proposed openstack/nova master: Trim fake_deserialize_context in test_conductor https://review.openstack.org/635859
17:29:26 openstackgerrit Balazs Gibizer proposed openstack/nova master: Cleanup inflight rpc messages between test cases https://review.openstack.org/637233
17:29:37 gibi mriedem: fyi, I think I got the fkr ^^
17:30:53 mriedem dansmith: maybe we were too hasty https://review.openstack.org/#/c/635146/10/nova/api/openstack/compute/views/servers.py@114
17:31:03 mriedem https://review.openstack.org/#/c/635147/13/api-guide/source/down_cells.rst@28
17:33:06 dansmith mriedem: hmm, is that going to refer to links in other apis that we won't support?
17:33:15 dansmith like /servers/uuid/somethingelse ?
17:33:16 mriedem no it's a ref back to itself
17:33:21 mriedem so nova show
17:33:31 dansmith I thought there were a couple of links, like to self, flavor, etc
17:33:45 mriedem flavor links would be under the flavor dict in the response
17:33:59 mriedem self is just GET /servers/{server_id}
17:34:00 mriedem "href": "http://openstack.example.com/v2/6f70656e737461636b20342065766572/servers/22c91117-08de-4894-9aa9-6ef382400985"

Earlier   Later