Earlier  
Posted Nick Remark
#openstack-nova - 2017-09-25
17:31:21 openstackgerrit Jianghua Wang proposed openstack/nova-specs master: Support virtual GPU resources https://review.openstack.org/450122
17:32:06 jianghuaw jaypipes, see the revised spec ^
17:32:07 jianghuaw thanks.
17:35:33 jianghuaw bauzas, I did some minor change basing on jaypipes' comments. Need your help to review it again. thanks. https://review.openstack.org/#/c/450122
17:53:44 openstackgerrit Mathieu Gagné proposed openstack/nova master: Regenerate and pass configdrive when rebuild Ironic nodes https://review.openstack.org/503088
17:53:53 jaypipes bauzas: k, I'm +2 on jianghuaw's spec
17:55:13 edmondsw mriedem yufei replied in https://review.openstack.org/#/c/502382
17:55:37 jianghuaw jaypipes, thanks very much:-)
17:56:07 edmondsw mriedem yufei I mean that I replied...
18:06:45 openstackgerrit Chris Dent proposed openstack/nova master: Move project_id and user_id to Allocation object https://review.openstack.org/500410
18:06:46 openstackgerrit Chris Dent proposed openstack/nova master: WIP: [placement] POST /allocations to set allocations for >1 consumers https://review.openstack.org/500073
18:06:46 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Allow _set_allocations to delete allocations https://review.openstack.org/501051
18:06:47 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Limit number of attempts to delete allocations https://review.openstack.org/507224
18:09:44 mriedem py35 unit test job seems to be jacked all of a sudden http://logs.openstack.org/47/498947/6/check/gate-nova-python35/15aee2f/console.html#_2017-09-25_16_45_38_542562
18:13:49 dansmith mriedem: that's odd
18:16:24 mriedem i've seen that in 2 jobs now
18:16:28 mriedem 2 changes i mean
18:17:33 openstackgerrit Merged openstack/nova-specs master: Support virtual GPU resources https://review.openstack.org/450122
18:18:05 dansmith is there something we can do about the quadrupling of the output on py35 due to warnings?
18:18:25 mriedem sdague was working on slimming some of those down already
18:18:32 dansmith okay
18:18:39 sdague I never got over to the py35 side
18:18:44 dansmith mriedem: so one of my patches failed with that, but it does show a test fail in the testr results
18:18:44 sdague I was trying to trim on the other side
18:18:54 sdague I could take a whack at the py35 one though
18:19:09 mriedem dansmith: yeah i was looking at your migration one
18:19:12 mriedem that's the link
18:19:24 mriedem Failed: 0
18:19:26 dansmith ah okay
18:19:33 mriedem {0} nova.tests.unit.test_rpc.TestRPC.test_cleanup_legacy_notifier_null [] ... inprogress
18:19:34 mriedem timeout?
18:19:39 mriedem i think that's a known one
18:19:40 mriedem yeah
18:19:40 sdague mriedem: yeh
18:19:51 sdague that's the issue that mtreinish is going to have to look at
18:20:00 sdague because that's something about the worker not returning
18:20:30 sdague it could be subunit parsing
18:20:49 dansmith does it actually take a while?
18:21:01 dansmith maybe that's the bug I'm seeing locally where some test worker takes a long time
18:21:45 sdague dansmith: I don't know, I've only seen it in the gate
18:21:56 dansmith sdague: I only see it on my 24T boxes
18:21:58 mriedem i've seen that TestRPC class timeout in lots of unit test jobs randomly
18:22:13 mriedem probably because there is global state involved in those
18:22:31 dansmith although in this gate run, it shows one worker as N/A which is not what I see
18:22:48 dansmith is it getting killed?
18:22:57 mriedem i just got this locally too
18:22:58 mriedem - Worker 1 (2790 tests) => N/A
18:24:29 mriedem oh gdi, TestRPC doesn't use nova.test.TestCase so we can't run it serialized either
18:24:33 mriedem https://bugs.launchpad.net/nova/+bug/1685333
18:24:34 openstack Launchpad bug 1685333 in OpenStack Compute (nova) "Fatal Python error: Cannot recover from stack overflow. - in py35 unit test job" [High,Confirmed]
18:25:18 mriedem sec, working on something
18:31:25 sdague mriedem: oh neat, if it doesn't inherit from nova.test.TestCase, that means that it doesn't have timeout support
18:32:24 mriedem yeah, twiddling this a bit
18:32:26 sdague mriedem: I could split up the base test class into some better slices so we don't loose that
18:32:39 mriedem that's kind of what i'm doing
18:32:48 mriedem but also looking at the oslo.concurrency lock fixtures
18:32:48 sdague ok
18:33:13 mriedem these tests muck with the global nova.rpc notification variables, so would need to be locked i think
18:33:23 sdague ah... fun
18:33:33 sdague well the segmentation is needed anyways
18:36:47 bauzas jaypipes: actually, when reading the nested RP spec, efried made me think of something
18:37:07 bauzas jaypipes: say I have two children RPs with eahc of them providing a specific inventory
18:37:38 bauzas jaypipes: do you see a way to ask for something like 'take me all of that', or just "take me that one"
18:38:06 bauzas the problem I have in mind is with resource usage that is sharded between children RPs
18:42:00 efried bauzas ++. If you recall, jaypipes volunteered to write a spec for the new syntax for this. I started scribbling some scenarios it needed to cover, and this was one of them. Take a look at the last two chunks starting L81 here: https://etherpad.openstack.org/p/nova-multi-alloc-request-syntax-brainstorm
18:44:01 efried bauzas This is in contrast to the scenario on L71 where we explicitly want the inventory to come from *different* RPs.
18:59:34 openstackgerrit Matt Riedemann proposed openstack/nova master: Make TestRPC inherit from the base nova TestCase https://review.openstack.org/507239
18:59:40 mriedem sdague: dansmith: ^ got distracted
19:01:43 mriedem damn pep8
19:01:54 openstackgerrit Matt Riedemann proposed openstack/nova master: Make TestRPC inherit from the base nova TestCase https://review.openstack.org/507239
19:14:40 mriedem alright danny boy, i've got a fresh devstack with the fake virt driver and noop quota driver, time to create 100 VMs
19:19:15 sdague mriedem: so, honestly, I wouldn't do it that way
19:19:25 sdague mriedem: let me take a different approach
19:26:57 mriedem i wonder if multi-create 100 vms will give me an http timeout
19:27:05 cfriesen policy question....would nova ever backport a microversion bump to a stable release?
19:27:19 mriedem nope
19:27:44 mriedem you want your embedded flavor thing in ocata don't you
19:27:59 cfriesen heh...nope. was just planning something
19:28:01 sdague cfriesen: microversions aren't really backportable
19:28:54 cfriesen was just wondering if I'd have to plan to be able to handle microversion bumps in bugfixes.
19:29:16 cfriesen this makes it easier
19:37:33 openstackgerrit Ed Leafe proposed openstack/nova master: Add Selection objects https://review.openstack.org/499239
19:37:33 openstackgerrit Ed Leafe proposed openstack/nova master: Add alternate hosts https://review.openstack.org/486215
19:37:34 openstackgerrit Ed Leafe proposed openstack/nova master: Set the Pike release version for scheduler RPC https://review.openstack.org/507245
19:42:02 dansmith mriedem: you're doing the fake virt devstack testing on my switch-to-the-new-thing patch?
19:42:38 mriedem dansmith: trying to get a baseline
19:42:44 mriedem straight curl with 100 instances is trivial
19:42:51 mriedem .004s
19:42:55 mriedem so booting 500 more
19:43:31 mriedem had to switch to curl to take out extra 5 seconds novaclient adds to nova list
19:43:41 dansmith heh
19:45:20 openstackgerrit Sean Dague proposed openstack/nova master: Break out BasicTestCase https://review.openstack.org/507253
19:45:31 sdague mriedem: that's an alternative
19:53:44 mriedem commented
19:53:49 mriedem i like mine better but i'm biased
19:55:02 openstackgerrit ayoung proposed openstack/nova master: Admin API Policy contingent on is_admin_project https://review.openstack.org/384148
19:55:44 dansmith I would rather not have another base-base-base test case class
19:55:56 dansmith I know it's not very OO, but we have a lot already
19:59:55 mriedem booting another 400 to get me to 1000
20:00:00 mriedem i figure that's a nice round number, and is our default limit

Earlier   Later