| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-12-07 | |||
| 13:19:03 | efried | jaypipes Though realistically, I'm not sure how much we can expect to merge the last two weeks of December. Do lots of people disappear? | |
| 13:19:21 | jaypipes | efried: yes | |
| 13:19:25 | efried | k | |
| 13:51:07 | openstackgerrit | Eric Fried proposed openstack/nova master: Reformat _get_all_with_shared https://review.openstack.org/512799 | |
| 13:59:58 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix 'force' parameter in os-quota-sets PUT schema https://review.openstack.org/523194 | |
| 13:59:59 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Deprecate file injection https://review.openstack.org/522027 | |
| 14:00:10 | mriedem | alex_xu: removed that file finally, thanks for pointing that out again ^ | |
| 14:01:14 | mriedem | sdague: can we get https://review.openstack.org/523194 in so i can get it backported to newton before eol | |
| 14:07:46 | sdague | mriedem: +2 from me | |
| 14:10:31 | alex_xu | mriedem: np, +w | |
| 14:10:41 | mriedem | thanks | |
| 14:12:26 | mriedem | the functional py35 logs are unreadable due to deprecation warnigns | |
| 14:12:28 | mriedem | *warnings | |
| 14:12:32 | mriedem | from oslo.context and oslo.policy | |
| 14:13:14 | openstackgerrit | Yikun Jiang (Kero) proposed openstack/nova master: Add pagination and changes-since for instance-actions https://review.openstack.org/326326 | |
| 14:13:35 | jianghuaw_ | bauzas, I think we can only enable one type for each RP (pgpu for libvirt; gpu group for xenapi). Then we can mapping the allocation to the single enabled type in that resource provider. | |
| 14:13:37 | fungi | jaypipes: wow, you almost make north carolina sound tame by comparison ;) | |
| 14:13:59 | fungi | (though in full disclosure, i was born in florida so can't really judge) | |
| 14:14:07 | jaypipes | fungi: :) | |
| 14:15:06 | mriedem | bauzas: https://review.openstack.org/#/c/508262/ - i think we should get that in and backported to avoid the tons of excessive logging about what state the computes are in when we're doing anything in the resource tracker | |
| 14:15:25 | jianghuaw_ | bauzas, it should work if we can mapping back from RP uuid to the PGPU/gpu group. | |
| 14:15:36 | mriedem | when i compared logs, it went from logging nearly 400 times to 35 | |
| 14:16:07 | jianghuaw_ | bauzas, for XenAPI we plan to use the gpu group's uuid as the VGPU RP's uuid. That should work. | |
| 14:19:22 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: update_cell allows more than once cell to have the same db/transport url https://review.openstack.org/518556 | |
| 14:19:30 | jianghuaw_ | bauzas, see this patch: https://review.openstack.org/#/c/521717 | |
| 14:19:38 | bauzas | mriedem: agreed | |
| 14:20:03 | bauzas | mriedem: planning to backport ? or want me to do such thing ? | |
| 14:20:40 | bauzas | jianghuaw_: I think we should discuss maybe later (I'm a but rushing this afternoon tbh) about how to have multiple supported types | |
| 14:20:52 | bauzas | for the moment, let's merge only one per compute in Queens | |
| 14:21:03 | jianghuaw_ | bauzas, sure. | |
| 14:21:08 | bauzas | we also need to have flavor traits for that, remember | |
| 14:21:35 | jianghuaw_ | bauzas, yes. that's not ready for go. | |
| 14:22:27 | jianghuaw_ | bauzas, Thanks for the comment on https://review.openstack.org/#/c/516899/ | |
| 14:22:41 | jianghuaw_ | I uploaded a new ps. | |
| 14:22:52 | efried | jaypipes I don't see a way around it - I'm going to inject series https://review.openstack.org/#/c/521605/ into the main nrp stack. | |
| 14:23:06 | jaypipes | efried: k | |
| 14:25:01 | mriedem | bauzas: i'm planning on backporting | |
| 14:27:29 | bauzas | mriedem: k, ping me when you're done | |
| 14:31:26 | bauzas | jianghuaw_: wait, just saw https://review.openstack.org/#/c/516899/30/nova/tests/unit/virt/xenapi/test_driver.py@400 | |
| 14:31:59 | bauzas | snap, missed https://review.openstack.org/#/c/516217/24/nova/virt/xenapi/driver.py@457 | |
| 14:32:17 | dansmith | jaypipes: that wasn't me dude.. I appreciate the undue credit and all, but ... :P | |
| 14:33:06 | jianghuaw_ | bauzas, yes. That's because XenServer can only support one VGPU per VM. | |
| 14:33:14 | bauzas | but in libvirt, max_unit = max(vgpus) | |
| 14:33:34 | bauzas | jianghuaw_: I think there is a confusion | |
| 14:33:44 | bauzas | ah ? | |
| 14:33:51 | jianghuaw_ | I saw that difference and I asked if libvirt can support multiple VGPUs. | |
| 14:34:04 | bauzas | in theory, one can create multiple mdevs in libvirt | |
| 14:34:19 | jianghuaw_ | There is no way to create multiple VGPU in XenServer at the moment. | |
| 14:34:33 | bauzas | jianghuaw_: that said, I haven't tested it yet | |
| 14:34:51 | bauzas | multiple VGPUs per instance, right? | |
| 14:36:16 | jianghuaw_ | bauzas, seems yes:-) | |
| 14:36:36 | jianghuaw_ | I asked XenServer developer. They said that restriction is in the tool stack - XAPI so it may work for libvirt. | |
| 14:37:06 | bauzas | jianghuaw_: given it's experimental for libvirt, I probably need to test that once I'm done with implementing it | |
| 14:37:34 | bauzas | but you're fortunate, you're at least 3 people working on the xen side, compared to one on libvirt :p | |
| 14:37:45 | bauzas | one being overcommitted :p | |
| 14:38:37 | jianghuaw_ | bauzas, That's true. We had 3 people. | |
| 14:38:43 | jianghuaw_ | :-) | |
| 14:38:57 | bauzas | you *had* ? | |
| 14:40:09 | jianghuaw_ | I hope we can go further to support multiple vGPU types and traits. But it still depends on n-rp and traits works which are not ready yet. So moving some effort to other feature. | |
| 14:40:20 | jianghuaw_ | that's why I said *had* | |
| 14:42:10 | bauzas | k | |
| 14:44:02 | jianghuaw_ | bauzas, but I do wish very very much to get the patches on single vGPU can be merged soon. Particularly the long vacation is approaching:-) | |
| 14:46:22 | jianghuaw_ | bauzas, but feel free to let me know if further change needed for https://review.openstack.org/#/c/516899/ | |
| 14:46:33 | jianghuaw_ | I'm happy to rework it. | |
| 15:03:47 | mriedem | gibi: ildikov: replied in https://review.openstack.org/#/c/525787/ | |
| 15:03:53 | mriedem | gibi: thanks for the thorough review as always | |
| 15:04:20 | ildikov | mriedem: Tnx, will check in a bit | |
| 15:04:26 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/ocata: Fix 'force' parameter in os-quota-sets PUT schema https://review.openstack.org/526426 | |
| 15:06:16 | mriedem | sdague: dansmith: bauzas: can we get these patches in for the recent cve fix (pike) and then i'll start prepping for a release https://review.openstack.org/#/q/topic:alternate/1664931+status:open | |
| 15:06:35 | dansmith | ya | |
| 15:07:22 | dansmith | mriedem: what is the pike only workaround? that hash in the commit message links to this | |
| 15:07:31 | mriedem | lyarwood: there are several patches with +2s on pike, can you go through those? https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/pike | |
| 15:07:48 | dansmith | oh wait | |
| 15:07:50 | mriedem | dansmith: this https://review.openstack.org/#/c/523213/4/nova/tests/functional/test_servers.py | |
| 15:07:52 | mriedem | the setUp | |
| 15:08:10 | dansmith | yeah, okay I was expecting something functional | |
| 15:08:10 | mriedem | i should have said, "in the functional test" or something | |
| 15:08:12 | dansmith | yeah | |
| 15:08:30 | dansmith | also it just links back to this series which was confusing me about where the thing was added | |
| 15:08:39 | dansmith | outside of gerrit that will link properly though so that's fine | |
| 15:09:15 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/newton: Fix 'force' parameter in os-quota-sets PUT schema https://review.openstack.org/526427 | |
| 15:09:19 | lyarwood | mriedem: yup will try, still handing over all of my tripleo work atm, hopefully back to nova full time next week btw | |
| 15:09:37 | mriedem | i anticipate your glorious return | |
| 15:12:52 | mriedem | sdague: you were +2 on this before i robustified the tests (copying efried's work) https://review.openstack.org/#/c/521947/ - that is something we'll need to get backported also | |
| 15:13:01 | gibi | mriedem: thanks for the reply in the attach flow patch. Now the BFV case is clear for me | |
| 15:13:05 | edleafe | dansmith: I have a question about the changes to the filter_scheduler._claim_resources() method | |
| 15:13:21 | mriedem | gibi: yeah that took me some time to figure out why those tests weren't working as i'd expected | |
| 15:13:39 | edleafe | dansmith: the docstring about the params doesn't match the params to the method | |
| 15:14:05 | edleafe | dansmith: https://github.com/openstack/nova/blob/master/nova/scheduler/filter_scheduler.py#L272-L293 | |
| 15:14:25 | mriedem | jgriffith: do you remember why you added this? https://review.openstack.org/#/c/525787/3/nova/virt/block_device.py@448 | |
| 15:14:35 | mriedem | jgriffith: doesn't seem necessary so i plan on removing it unless there was a need for this | |
| 15:14:40 | dansmith | edleafe: is that a change I made? | |
| 15:15:40 | edleafe | dansmith: I think so. Were there any other changes to _claim_resources? | |
| 15:15:58 | dansmith | edleafe: I dunno, let me dig up history.. what's your question though? | |
| 15:15:58 | edleafe | dansmith: just the rebuild check, right? | |
| 15:16:45 | edleafe | dansmith: rebasing my series. The docstring says that it is getting and instance UUID, a HostState object, and allocation_requests | |
| 15:17:00 | mriedem | gibi: do you want me to remove the 4 changes at the top of https://review.openstack.org/#/c/525787/3/nova/tests/unit/virt/test_block_device.py where i'm setting the attachment_id in those *_driver_bdm class dicts? | |
| 15:17:07 | edleafe | but it's still just getting a spec_obj, instance uuid and allocation_requests | |
| 15:17:13 | dansmith | edleafe: This is the change I didn't change the params: https://review.openstack.org/#/c/521662/10/nova/scheduler/filter_scheduler.py | |
| 15:17:28 | mriedem | gibi: maybe i should just remove the key from the *_driver_bdm variables since they are set in setUp anyway | |