Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-10-04
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/
12:58:57 bauzas I did that for German \o/
12:59:21 bauzas und jetzt I spreche Deutch
12:59:25 bauzas Ich*
13:00:10 sean-k-mooney bauzas: if you ever want to lean a languge that no one will under stand they have an irish course too
13:03:23 bauzas sean-k-mooney: I saw this
13:03:33 bauzas there is also High Valeryan and Klingon
13:06:54 sean-k-mooney bauzas: both are proably more useful then irish that said it was nice to have a language you could use to gossip about people abroad on school trips lol only use of irish i have ever had
13:07:03 efried jetzt spreche ich <== with an adjective in the mix, you put the verb before the subject. Or something.
13:07:27 efried or whatever "jetzt" is, not an adjective
13:22:10 jaypipes gibi: +2 from me on claim_resources(). I will let efried or mriedem +W.
13:22:45 gibi jaypipes: thanks a lot. efried had a bunch of comments so I feel he is the one who can +W it
13:31:10 openstackgerrit Balazs Gibizer proposed openstack/nova master: Run ServerMovingTests with nested resources https://review.openstack.org/604084
13:31:10 openstackgerrit Balazs Gibizer proposed openstack/nova master: Refactor allocation checking in functional tests https://review.openstack.org/607287
13:31:11 openstackgerrit Balazs Gibizer proposed openstack/nova master: Consider nested allocations during allocation cleanup https://review.openstack.org/606050
13:31:11 openstackgerrit Balazs Gibizer proposed openstack/nova master: Ignore forcing of live migration for nested instance https://review.openstack.org/605785
13:31:12 openstackgerrit Balazs Gibizer proposed openstack/nova master: Run negative server moving tests with nested RPs https://review.openstack.org/604125
13:31:12 openstackgerrit Balazs Gibizer proposed openstack/nova master: Ignore forcing of evacuation for nested instance https://review.openstack.org/606111
13:33:20 gibi bauzas: FYI, the nested series now up to date all the way to the top https://review.openstack.org/#/c/604125/
13:43:19 openstackgerrit Surya Seetharaman proposed openstack/nova master: [WIP] Refactor scatter-gather utility to return exception objects https://review.openstack.org/607934
13:50:13 openstackgerrit Jack Ding proposed openstack/nova master: Handle missing marker during online data migration https://review.openstack.org/605164
14:02:19 dansmith did I miss that the meeting this week was canceled or something?
14:03:06 gibi dansmith: I think I did not get a request from melwitt to chair it but I can
14:03:25 dansmith meh
14:03:26 gmann not sure. I was also checking meeting channel
14:03:32 efried we have an important topic to discuss, HPET for libvirt.
14:03:34 bauzas hah, I just asked the question in -meeting
14:03:36 efried they're expecting it.
14:03:45 bauzas efried: and what about HCATTLE ?
14:03:56 efried oy vay
14:04:06 sean-k-mooney efried: so #openstack-meeting time i guess
14:04:24 efried yup
14:11:10 mrch_ can i prevent the nova.compute.resource_tracker spaming this: nova.compute.resource_tracker [req-e23cf459-506f-42d3-ac5d-73d87b1e5ba9 - - - - -] [instance: 8ecbbdb1-bad7-434b-8d09-265964ca9c7e] Instance not resizing, skipping migration. when 5 hosts spam this about one an the same vm, an i got 10 vms of that kind, its annoying as f

Earlier   Later