| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-04 | |||
| 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. | |
| 12:30:53 | cdent | 2 even | |
| 12:31:05 | jaypipes | cdent: touche :) | |
| 12:31:12 | sean-k-mooney | so in that case for a delete cant nova just do that and pass the instance uuid? | |
| 12:31:18 | gibi | sean-k-mooney: it is complicated if the consumer has allocations on other computes as well | |
| 12:31:42 | gibi | sean-k-mooney: and it is the case for evacuate :/ | |
| 12:31:54 | jaypipes | sean-k-mooney: sure it can. the issue is edge cases... gibi's func test patch outlines those cases well. lemme grab you a link. | |
| 12:32:24 | gibi | jaypipes: I think I'm failing to grasp what is exactly your suggestion for claim_resources() call | |
| 12:32:27 | openstack | Launchpad bug 1763043 in OpenStack Compute (nova) "Unnecessary "Instance not resizing, skipping migration" warning in n-cpu logs during live migration" [Medium,In progress] - Assigned to Matt Riedemann (mriedem) | |
| 12:32:27 | mrch_ | https://bugs.launchpad.net/nova/+bug/1763043 ( Instance not resizing, skipping migration.) well its not unnecessary because 70% of them have locked nova/cinder disk, got around a dozend of them any ideas, excetp "rbd lock remove" till the end of my life? | |
| 12:32:53 | sean-k-mooney | gibi: for evacuate would we not use a migration uuid to hold the dest allocations and then not delete the source allocation and swap it over like we do for cold migrate? | |
| 12:33:14 | gibi | sean-k-mooney: that would be ideal, but does not happen today | |
| 12:33:15 | jaypipes | sean-k-mooney: see very bottom of this file: https://review.openstack.org/#/c/604084/3/nova/tests/functional/test_servers.py | |
| 12:33:17 | sean-k-mooney | im really not familar enough with this code unfortuenetly | |
| 12:33:26 | gibi | sean-k-mooney: I have a todo from the PTG to improve that as well | |
| 12:33:35 | jaypipes | sean-k-mooney: those tests and comments from gibi highlight well the issue. | |
| 12:33:39 | jaypipes | issues... | |
| 12:35:41 | bauzas | jaypipes: flush the toilets | |
| 12:35:50 | sean-k-mooney | jaypipes i have no doubt gibi has reasoned about this and the edgecase far better then i :) espcially since i jsut stared looking at the patch but ya just providing my assumtions in case that help with any that might have been made :) my assumetion of how this should work likely diverge hevily form how it does | |
| 12:36:02 | gibi | jaypipes: there is stuctural change between 1.12-1.28 but there is no strucutral change when we step from 1.28 to 1.29 in a_c but I don't know what you want to suggest | |