Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-10-04
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
14:12:57 efried mrch_: We're in the nova meeting atm; can you ask again at the top of the hour?
14:13:43 efried It looks like this is happening because you have some stale migrations in the database; can you clean those up?
14:15:56 mrch_ efried: shure
14:15:56 mrch_ efried
14:18:05 mrch_ efried
14:18:06 mrch_ efried: concidering db, but i cant wait, i stay in chat just write ill see it tomorrow
14:18:50 efried mrch_: Okay. I personally don't know how to clean up the db, but hopefully one of the wizards can advise once the meeting is over.
14:58:22 melwitt gibi: thank you for running the nova meeting, it completely slipped my mind this time. apologies
15:00:26 gibi melwitt: no worries
15:00:35 mhen o/

Earlier   Later