| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-25 | |||
| 17:13:41 | jianghuaw | jaypipes, the default value 1 for display heads is requested by bauzas to cover the case where the head-counts don't return. | |
| 17:13:57 | jaypipes | jianghuaw: understood, but that's wrong. :) | |
| 17:14:38 | jaypipes | jianghuaw: if the virt driver cannot determine head counts, it simply should not write an inventory record for the VGPU_DISPLAY_HEAD resource class | |
| 17:14:44 | jianghuaw | it's possible if the vGPU doesn't support multiple-heads. By default at least it should support one head? | |
| 17:15:30 | jianghuaw | Then does it mean these vGPU can't be scheduled if it's requesting for one display head? | |
| 17:15:43 | openstackgerrit | Merged openstack/nova master: Copy some tests to a cellsv1 mixin https://review.openstack.org/505442 | |
| 17:16:19 | jaypipes | jianghuaw: no, the opposite. by not having an inventory record for VGPU_DISPLAY_HEAD, that means all the pGPUs (or GPU groups) would be schedulable. | |
| 17:16:45 | cdent | jaypipes: in a choice between another process (just for placement-periodics) and cron, I’d definitely choose cron | |
| 17:16:59 | jaypipes | jianghuaw: if the hypervisor cannot determine display heads, then the flavor should not request VGPU_DISPLAY_HEAD resources | |
| 17:17:31 | cdent | mriedem, edleafe, dansmith: your thoughts on jay’s comments on https://review.openstack.org/#/c/504540/ encouraged | |
| 17:17:56 | jaypipes | jianghuaw: the problem of having an inventory of VGPU_DISPLAY_HEAD=1 would mean only a single instance requesting VGPU_DISPLAY_HEAD:1 would be possible on the host. | |
| 17:18:32 | jianghuaw | jaypipes, ah, I see. | |
| 17:18:47 | jianghuaw | yes, you're correct. | |
| 17:19:07 | jianghuaw | jaypipes, thanks for pointing it out:-) | |
| 17:20:40 | mriedem | gibi: oops something failed in the rebase here https://review.openstack.org/#/c/499539/9 | |
| 17:21:06 | gibi | gibi: looking | |
| 17:21:08 | gibi | mriedem: looking | |
| 17:21:10 | mriedem | https://review.openstack.org/#/c/499539/9 | |
| 17:21:11 | mriedem | oops | |
| 17:21:16 | mriedem | TypeError: _delete_and_check_allocations() takes exactly 2 arguments (4 given) | |
| 17:21:57 | gibi | OK I can fix that up quickly | |
| 17:24:08 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Moving more utils to ServerResourceAllocationTestBase https://review.openstack.org/499539 | |
| 17:24:09 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Test resource allocation during soft delete https://review.openstack.org/495159 | |
| 17:24:09 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: factor out compute service start in ServerMovingTest https://review.openstack.org/503037 | |
| 17:24:59 | gibi | mriedem: it should be better now | |
| 17:25:13 | mriedem | ok | |
| 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 | |