Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-10-04
11:49:42 openstackgerrit Surya Seetharaman proposed openstack/nova master: [WIP] Refactor scatter-gather utility to return exception objects https://review.openstack.org/607934
11:52:29 jaypipes gibi: yup, on it.
11:52:41 gibi jaypipes: thanks a lot
11:54:17 bauzas sean-k-mooney: back there
11:54:25 bauzas sean-k-mooney: if you wanna continue to discuss...
11:54:54 bauzas gibi: don't worry about the runway slot, now that I'm done with the reshaper change, your series is my top prio
11:55:10 gibi bauzas: cool, thanks
11:55:42 bauzas gibi: so, the above means that I can review it, right?
11:56:46 gibi bauzas: it means that tha last patch of consumer gen is updated with fixes based on jaypipes and efried comments, there are patches top of that that also up to date til https://review.openstack.org/604083 I'm fixing comment in the rest as we speak
11:56:58 bauzas gibi: okay, will look later today
11:57:26 bauzas gibi: FWIW I have a machine with GPU devices so I can test most of your series
11:57:38 gibi bauzas: sounds cool :)
11:58:26 gibi bauzas: so far I relied on functional test cases. Fortunately the resource allocation handling these patches change are possible to cover with functional
11:59:21 gibi bauzas: the physical consumpton of VGPUs are something where my functional test case wont be enough
11:59:36 sean-k-mooney jaypipes: bauzas gibi so in case you missed it earlier i think i figured out a way to test pci passthough, sriov, and some other things like livemigration with the same in the gate using the netdevsim kernel module
11:59:54 gibi sean-k-mooney: that is really good news!
11:59:58 bauzas gibi: I mean, I could just test your series with my reshape change
12:00:14 bauzas gibi: so that I could be sure we would be able to boot a flavor asking for VGPUs
12:00:24 bauzas (in a nested worldà
12:00:26 sean-k-mooney i also think that can be hacked to pretend to be vgpus i need to investgate that futher
12:00:30 gibi bauzas: yeah allocate, then rehape, then allocate again is something that needs coverage
12:00:44 bauzas gibi: I tested all of that with my single change
12:00:49 gibi bauzas: cool
12:00:51 bauzas gibi: but of course the boot failed
12:01:00 bauzas gibi: since I wasn't using your series
12:01:13 bauzas what I could do is just to pick your series, and do the same
12:01:19 gibi bauzas: I assume it will work with my series included
12:01:26 bauzas gibi: that's my assumption too
12:01:32 bauzas and the functional test shows it
12:01:39 bauzas but a real evidence is better, I guess
12:01:45 gibi bauzas: totally agree
12:02:05 bauzas sean-k-mooney: WDYM by netdevsim module ?
12:02:37 sean-k-mooney it is a kernel module adding in kernel 4.16 specifcally to allow testing of hardware offloads without hardwar
12:02:44 jaypipes sean-k-mooney: you'll excuse my skepticism until I see a real functional test of those items :)
12:03:00 sean-k-mooney bauzas: it allows you to create pci device that support mdevs and sriov
12:03:10 sean-k-mooney and it support ebpf too
12:03:10 bauzas sean-k-mooney: but it requires 4.16, right?
12:03:19 sean-k-mooney yep so a fedora 28 job
12:03:21 bauzas which could be a problem
12:03:37 jaypipes sean-k-mooney: that said, I'm still supportive of this netdevsim effort. ANYTHING is better than what we have now, which is pretty much nothing.
12:03:38 sean-k-mooney fedora comes with 4.17
12:04:36 bauzas sean-k-mooney: but bionic comes with 4.15 https://packages.ubuntu.com/bionic/linux-image-generic
12:04:51 bauzas so it wouldn't be a classic upstream gate job
12:05:04 sean-k-mooney jaypipes: ya i just learned about it yesterday so still doing reasarch but since i plan on working on sirov livemigration this cycle i would like to try to create an experimental job with this moduel to test it
12:05:19 bauzas sean-k-mooney: I was also considering the use of fake libvirt
12:05:23 sean-k-mooney bauzas: we have fedroa 28 images avaliable in the upstream gate for testing
12:05:27 bauzas couldn't that be simplier ?
12:05:49 sean-k-mooney bauzas: it could be this would allow tempest testing not just functional
12:06:28 bauzas sean-k-mooney: for SR-IOV it could be interesting
12:06:42 bauzas sean-k-mooney: for VGPU, I just feel it's unnecessary thru tempest
12:06:50 bauzas a functional test in-tree is better IMO
12:07:02 sean-k-mooney yep it also support things like configring rate limiting on the vf and trusted vfs
12:07:32 bauzas sean-k-mooney: just to make it clear, I was considering use of https://libvirt.org/drvtest.html
12:08:24 sean-k-mooney ok but i doubt that will support the featue we want to test
12:09:21 sean-k-mooney on testing with real hardware there is also this change https://review.openstack.org/#/c/607686/ :)
12:09:22 jaypipes sean-k-mooney: isn't artom working on that as well? (sriov live migration...)
12:09:32 jaypipes sean-k-mooney: or is artom focused on NUMA stuffs?
12:09:39 sean-k-mooney jaypipes: artom is working on numa
12:09:42 jaypipes ah, gotcha
12:09:56 sean-k-mooney im goning to do the sriov part
12:10:11 jaypipes sean-k-mooney: you're both brave men.
12:10:20 sean-k-mooney or dumb
12:10:25 jaypipes sean-k-mooney: I wouldn't touch that stuff with a ten foot pole.
12:10:39 jaypipes sean-k-mooney: the closest I'll get is doing some reviews for ya ;)
12:11:36 sean-k-mooney well i keep finding bugs in livemigration that i have to fix first related to the multiple port bindings on both the nova and neutron sides
12:12:50 sean-k-mooney so first im going to try and fix all those bugs then sriov live migration. i think neutron forgot to update teh sriovnic agent and driver to support multiple port binding so i have to fix that first
12:13:47 artom jaypipes, since you mentioned it, review pretty please https://review.openstack.org/#/c/599587/ ? ;)
12:14:00 artom But yeah, there's going to be some overlap/cooperation
12:14:13 artom Also, the mellanox guys were interested in SRIOV live migration, not sure what happened with that
12:14:53 sean-k-mooney artom: i talked to moshele last week. ill try and work with them if they want to help.
12:15:05 artom sean-k-mooney, ah, cool
12:15:09 sean-k-mooney artom: moshele said someone on his team was working on a poc
12:15:28 artom Hrmm, I thought they were going to propose a spec first?
12:15:40 sean-k-mooney well i already wrote one
12:15:56 sean-k-mooney artom: https://review.openstack.org/#/c/605116/
12:16:03 artom sean-k-mooney, thanks, was about to ask
12:19:44 sean-k-mooney jaypipes: bauzas gibi sorry your conversation got a little derailed by that but i think using the new vexhost physical gpu nodes in an experimental job would also be very valueable for testing both reshaper stuff and vgpus
12:20:55 jaypipes sean-k-mooney: but that would require us having to talk to mnaser and we ALL know that's not a good idea!
12:21:18 jaypipes artom: queued that up behind the gibster.
12:21:46 jaypipes gibi: OK, so... question on your response about the microversion 1.29 thing in https://review.openstack.org/#/c/583667/25/nova/scheduler/client/report.py...
12:22:09 sean-k-mooney jaypipes: :) well you could ignore him and just submit jobs when https://review.openstack.org/#/c/607686/ is merged
12:23:05 gibi jaypipes: looking..
12:23:20 jaypipes gibi: what is API 1.29 changing about GET /a_c's return?
12:23:26 jaypipes gibi: you mention this: "So by supporting nested a_c we implicitly force nova to at least support 1.29 >= in claim_resources too."
12:23:54 jaypipes gibi: but I'm wondering what changes in the allocation_request part of the a_c response to warrant a change in this code.
12:24:09 sean-k-mooney jaypipes: isnt 1.29 the microverion that adds nested allocation candiates?
12:24:48 jaypipes sean-k-mooney: but it's not "nested allocation candidates" really... the allocation request part of the response is still just a flat list of providers and the resource amounts being consumed from each.
12:25:13 jaypipes or at least, that's what I thought...
12:25:56 sean-k-mooney jaypipes: you are proably right i just have a vague recolection from the demo at the ptg that there was a reson this microverion was need for nested allocations
12:27:04 gibi jaypipes: technicall the allocations structure is unchanged in 1.29 but handling the fact that now more than one RP can be in an allocation candidate needs code change in multiple places in nova. Some of them is trivially missed in first patch that enables nested a_c in nova hence the expectedFailures in the functional test
12:28:18 gibi jaypipes: for example nova assumes that deleting an instance allocation from a compute is as easy as deleting the allocation from the compute RP
12:28:35 sean-k-mooney gibi: if the allocation candiates are a flat list as jaypipes says above is the provider topology captured in the summery?
12:29:00 gibi sean-k-mooney: yes, parent_rp_uuid is in the summary part
12:29:15 gibi s/parent_rp_uuid/parent_provider_uuid
12:29:25 jaypipes sean-k-mooney: yeah, it's in the provider_summaries part of the response, not the allocation_requests part of the response, which is what I was alluding to above.
12:29:54 sean-k-mooney so in the delete case nova now needs to delete the allocation from all resouce providers in the list instead of just one delete
12:30:04 jaypipes sean-k-mooney, gibi: and we don't pass the provider_summaries response to the claim_resources() method (only the allocation_request part) which is why I was asking about that comment from gibi on the claim_resources() patch.
12:30:20 gibi sean-k-mooney: exactly. It is implemented in https://review.openstack.org/#/c/606050/
12:30:21 sean-k-mooney i assume there is no api to say delete all allocation for this consumer uuid?
12:30:41 jaypipes sean-k-mooney: there is, yes.

Earlier   Later