Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-12-07
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 mriedem i should have said, "in the functional test" or something
15:08:10 dansmith yeah, okay I was expecting something functional
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 edleafe dansmith: just the rebuild check, right?
15:15:58 dansmith edleafe: I dunno, let me dig up history.. what's your question though?
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
15:17:33 mriedem to avoid confusion about why they are there
15:17:36 edleafe but it's still just getting a spec_obj, instance uuid and allocation_requests
15:17:39 edleafe oops
15:18:02 edleafe ok, then I'll just change the docstring to be correct
15:18:12 dansmith edleafe: yeah, I'm not sure where that docstring diverged from the signature, but it's clearly wrong
15:18:18 edleafe I was wondering if there were other changes being merged that affected it
15:18:31 edleafe dansmith: got it
15:18:49 gibi mriedem: just remove that is anyhow set in the setUp
15:19:34 gibi mriedem: but I that is the 4 change in top of the test_block_device.py :)
15:21:02 edleafe dansmith: huh, it was in jaypipes's change for adding claiming back in July. I guess I had corrected it in my series so long ago, that I thought the merge conflict from your change also changed the docstring
15:21:06 sdague mriedem: yeh, +2 on that still
15:21:20 mriedem sdague: thanks
15:21:26 dansmith edleafe: that sounds like him
15:21:35 edleafe dansmith: :)
15:23:03 openstackgerrit Eric Fried proposed openstack/nova master: SchedulerReportClient._get_providers_in_tree https://review.openstack.org/520663
15:23:03 openstackgerrit Eric Fried proposed openstack/nova master: SchedulerReportClient._get_providers_in_aggregates https://review.openstack.org/521097
15:23:04 openstackgerrit Eric Fried proposed openstack/nova master: Traits ops on ProviderTree https://review.openstack.org/521605
15:23:04 openstackgerrit Eric Fried proposed openstack/nova master: Aggregate ops on ProviderTree https://review.openstack.org/526216

Earlier   Later