Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-10-04
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
12:37:46 jaypipes gibi: I was questioning the need to "pin" the claim_resources() API microversion to 1.29 since there was no change to the allocation_request part of the a_c response.
12:39:14 gibi jaypipes: sure claim_resources can work with 1.28 even if a_c used 1.29. I think we are not even bumping claim_resources to 1.29 when we bump a_c to 1.29
12:39:57 gibi jaypipes: this path bumps a_c to 1.29 https://review.openstack.org/#/c/585672 but not the claim_resources
12:41:13 jaypipes gibi: k, cool.
12:41:41 jaypipes gibi: again, I was just responding to your comments on https://review.openstack.org/#/c/583667/25/nova/scheduler/client/report.py where you said this:
12:41:42 jaypipes "Therefore scheduler passes down >= 1.29 when calling claim_resources with the selected allocation candidate. So by supporting nested a_c we implicitly force nova to at least support 1.29 >= in claim_resources too. "
12:42:11 jaypipes gibi: but, no worries, I'll stop bothering you and get back to reviewing the last revision in that patch :)
12:42:30 gibi jaypipes: so you suggets to drop the logic that passes version from a_c to claim_resources?
12:42:51 jaypipes gibi: yeah, might be useful...
12:42:53 gibi jaypipes: that logic is the one that forces claim_resources to adapt to 1.29
12:43:06 jaypipes gibi: since technically there's nothing about 1.29 that affects claim_resources.
12:43:34 jaypipes gibi: and the allocation_request_version that gets passed to claim_resources() is all about the structure of the allocation_request part of the payload.
12:43:57 jaypipes gibi: but it's really not a huge deal :)
12:44:05 gibi jaypipes: jeah for 1.29 we don't need that but for the bump of 1.12 - 1.28 we need to know that the a_c was used with 1.28
12:44:10 jaypipes gibi: like I said, I'll go back to my last revision review :)
12:44:30 gibi jaypipes: I let you review :)
12:44:48 jaypipes gibi: elnézést a zavarásért!
12:45:38 jaypipes I imagine gibi laughing at Google Translate's poor translation
12:45:58 gibi jaypipes: what was the English expression you translated?
12:46:01 gibi :)
12:46:05 jaypipes "Sorry to bother"
12:46:08 jaypipes lol
12:46:18 jaypipes what does it mean? :)
12:46:32 jaypipes "Happy cows love coding" or something wacky like that?
12:47:57 gibi no it is not that far
12:50:27 gibi jaypipes: what you used is more for the case when you want to approach a stranger, e.g. as a first sentence before you ask for direction
12:51:03 gibi so it is super polite
12:51:52 gibi but yeah you basically asked for forgiveness for the interruption
12:52:06 gibi so the intention is clear
12:54:42 jaypipes hehe
12:58:43 bauzas jaypipes: gibi: https://www.duolingo.com/course/hu/en/

Earlier   Later