| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-14 | |||
| 12:11:05 | gibi | bauzas: that is the only difference from the generic call | |
| 12:11:48 | gibi | I mean https://review.openstack.org/#/c/563269/26/nova/compute/utils.py@734 | |
| 12:30:32 | bauzas | gibi: sure, but the action is always the same ? | |
| 12:32:23 | gibi | bauzas: if the action mean calling a specific constructor then my answer is no. if you mean instantiating a payload class and then a notification class and then calling emit() then yes | |
| 12:32:40 | gibi | so the high level pattern is the same | |
| 12:32:59 | gibi | and this pattern could be factored out as a generic thing | |
| 12:33:16 | gibi | parameterized with payload class and notification class | |
| 12:33:20 | bauzas | gibi: sure, that's why I don't like to see a compute modification | |
| 12:33:25 | bauzas | anyway | |
| 12:33:52 | openstackgerrit | Corey Bryant proposed openstack/nova master: Fix execute mock for test_convert_image_with_errors https://review.openstack.org/575305 | |
| 12:34:17 | crazik | hi @ll | |
| 12:35:57 | crazik | is there any way to clean migration list? | |
| 12:45:41 | gibi | Kevin_Zheng: I left a suggesting in https://review.openstack.org/#/c/564092 | |
| 13:04:10 | mriedem | jmlowe: melwitt: i was thinking about that microversion troubleshooting issue, and we could put something in here https://developer.openstack.org/api-guide/compute/microversions.html or we also have a troubleshooting section in the admin guide https://docs.openstack.org/nova/latest/admin/support-compute.html | |
| 13:04:28 | mriedem | latter is probably better | |
| 13:07:01 | mriedem | jmlowe: also, not sure but we could consider logging something in here https://github.com/openstack/nova/blob/2b9c7970fcdd9c7747656d662319c811a9895c20/nova/api/openstack/__init__.py#L101 | |
| 13:07:14 | mriedem | if you're using v2 compat mode and users are hitting your cloud with microversion requests which are just being ignored | |
| 13:10:55 | gibi | mriedem: hi! I found an issue in https://review.openstack.org/#/c/563269/26/nova/tests/functional/notification_sample_tests/test_instance.py@1019 I can jump on it and fix it if you wish | |
| 13:11:24 | mriedem | gibi: go for it, i haven't gotten that far yet, was planning to review that today | |
| 13:11:30 | openstackgerrit | Merged openstack/nova stable/queens: [Stable Only] Initialise failed_builds in IronicNodeState https://review.openstack.org/574997 | |
| 13:11:34 | mriedem | i've been fixing the small things in this series myself to keep it going | |
| 13:12:12 | gibi | mriedem: OK | |
| 13:33:48 | openstackgerrit | Eric Fried proposed openstack/os-vif master: doc: Mention second arg to (un)plug in docs https://review.openstack.org/575151 | |
| 13:38:43 | artom | sahid, so, about NUMA live migration | |
| 13:39:19 | artom | Coming from a place of complete ignorance of the resource tracker and claims, and having quickly talked this over with mriedem and dansmith last night, my understanding was that we'd need to resource tracker to track live migrations in order to do claims, and that it's a massive rabbit hole we don't want to get into | |
| 13:39:55 | artom | The easier solution is to ignore claims entirely and wait for NUMA to be done in placement, and let the scheduler update allocations (we already do that for live migration, but not for NUMA resources) | |
| 13:40:20 | artom | sahid, you seem to be saying that doing claims for live migration isn't as massive a rabbit hole as we think it is? | |
| 13:40:40 | melwitt | mriedem: good ideas | |
| 13:42:12 | sahid | artom: well my thinking is that we have everything ready in claim, it's going to do all the work that you are doing, check the new numa topology and store it | |
| 13:42:37 | artom | sahid, yeah, I saw it being used for cold migrations | |
| 13:42:53 | artom | I still need to wrap my head around how to use it properly | |
| 13:43:09 | sahid | artom: did you see my last comment? | |
| 13:43:23 | artom | sahid, you mean about _move_claim in resource_tracker? | |
| 13:43:35 | artom | That's a "private" method, I can't just call that directly, surely? | |
| 13:44:15 | sahid | artom: you just have to create a public one that will prepare it and pass everyting needed | |
| 13:45:42 | artom | sahid, right, duh :/ | |
| 13:45:53 | artom | sahid, I'll see if I can make sense of it | |
| 13:45:59 | artom | I do like the idea of reusing existing code | |
| 13:46:03 | artom | (obviously) | |
| 13:47:14 | sahid | more of that, you can't just really check in pre-live-migration, a live-migration process can take time so you have to make destination node to return accurate resources | |
| 13:47:23 | sahid | which is basically one of the role of the claim thing | |
| 13:47:46 | artom | I just don't want this to turn into a massive piece of work that'll get replaced by placement next cycle | |
| 13:48:10 | artom | sahid, oh yeah, we've know from the start that it was going to be racy | |
| 13:48:36 | artom | https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/numa-aware-live-migration.html#alternatives the para before that | |
| 13:48:57 | sahid | more of that if all of that is going to be replaced by placement so it's better to continue with the same mech | |
| 13:49:26 | mriedem | artom: sahid: the point of "claiming" resource allocations in the scheduler via placement is so we don't have to do the racy late claim on the compute | |
| 13:49:34 | mriedem | eventually all of that claims code gets dropped | |
| 13:49:40 | mriedem | in the RT i mean | |
| 13:50:03 | mriedem | once we have numa / pci modeling in placement / scheduler and once we no longer have the caching scheduler | |
| 13:50:15 | melwitt | nova meeting in 10 minutes | |
| 13:50:21 | mriedem | that's not going to happen in rocky though | |
| 13:54:26 | artom | mriedem, sahid, yeah, that's sort of the thing I'm trying to decide - how much work would it be to do RT claims for live migration *now*, knowing that it'll all get dropped in Stein (?) in favor of placement | |
| 13:54:48 | mriedem | artom: no guarantees on dropping that claims code in stein | |
| 13:54:50 | mriedem | i doubt it honestly | |
| 13:54:53 | artom | Last night it was apparently "a lot of work, don't bother" | |
| 13:55:03 | artom | But sahid's saying it's not that hard | |
| 13:55:28 | mriedem | numa has to be modeled in placement inventory first, and i don't think that spec landed in rocky | |
| 13:55:44 | mriedem | so you're looking at reporting numa inventory to placement from the comptues in stein at the earliest | |
| 13:56:04 | mriedem | we *might* be able to drop the caching scheduler in stein because we have heal_allocations now | |
| 13:56:29 | dansmith | I don't think that adding this to live migration regresses the claim situation at all righ? | |
| 13:56:41 | dansmith | we can already migrate instances where we have no resources today | |
| 13:56:53 | dansmith | being able to do instances with numa doesn't make that worse, right? | |
| 13:57:30 | mriedem | i'm not really following, and i'd really need to read the spec before actually intelligently discussing what was proposed for this | |
| 13:58:29 | mriedem | melwitt: jmlowe: ok i can try to hack some quick thing into the troubleshooting guide for "why aren't my microversion-based requests being honored?" | |
| 13:58:46 | artom | mriedem, https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/numa-aware-live-migration.html It's a quick read, I pinky-swear | |
| 13:58:58 | jmlowe | I answered my own question on ask openstack about this | |
| 13:59:06 | mriedem | jmlowe: link? | |
| 13:59:17 | jmlowe | karma 1, so it may never see the light of day | |
| 13:59:30 | mriedem | jmlowe: might still be good to put into our troubleshooting docs | |
| 13:59:47 | mriedem | since we probably don't leverage the fact we have those at all enough | |
| 13:59:51 | jmlowe | absolutely | |
| 14:00:16 | jmlowe | https://ask.openstack.org/en/question/114805/why-is-nova-ignoring-microvesions/#114806 | |
| 14:00:20 | mriedem | artom: i plan on getting to it eventually, just busy atm | |
| 14:00:24 | mriedem | jmlowe: thanks | |
| 14:00:31 | artom | mriedem, heh, no worries :) | |
| 14:00:46 | jmlowe | also the follow up https://ask.openstack.org/en/question/114808/why-is-nova-cli-not-using-https/#114809 | |
| 14:01:48 | mriedem | jmlowe: i keep getting a "Sorry, this content is not available" error on the first one, | |
| 14:01:55 | mriedem | maybe it has to go through screening first | |
| 14:02:00 | mriedem | to de-pence-ify it | |
| 14:02:03 | mriedem | i know you're in indiana | |
| 14:02:11 | jmlowe | right, awaiting moderator approval | |
| 14:02:20 | jmlowe | too soon | |
| 14:02:21 | sahid | artom: i don't want to make any troubles on your implementation, it's just if we can reuse what we already have that will limit the code introduced, | |
| 14:02:25 | jmlowe | :) | |
| 14:02:30 | sahid | also when it will be the time to drop claim, we could think of that in one step, everything will be grouped | |
| 14:02:57 | sahid | but if there is already a preferece for a new impl, i will remove my -1 | |
| 14:03:06 | artom | sahid, heh, I'm just trying to find the balance between doing it right and getting it merged | |
| 14:03:16 | sahid | artom: yes i guess :) | |
| 14:03:35 | artom | Given that https://review.openstack.org/#/c/244489/ has languished in review purgatory for literally *years*, maybe claims isn't the most mergeable way of doing it ;) | |
| 14:03:41 | sahid | artom: have a look at what i suggested, that should be really easy to implement | |
| 14:04:10 | sahid | artom: it's because it's all in one patch, if you can make it comprhensible i guess that will help | |
| 14:04:20 | artom | sahid, in the interest of good faith, I will :) | |
| 14:04:30 | sahid | so you can focus on updating the guest domain XML | |
| 14:04:52 | artom | But the argument of "it's all already a mess with no claims and resource tracking, so just making it suck less with NUMA" is pretty strong as wlel | |
| 14:05:21 | stephenfin | Random question: is there a way to rerun only the tests that failed on the last run? I recall this being a ((o)s)testr feature | |
| 14:05:27 | stephenfin | efried, mdbooth: ^ ? | |
| 14:05:49 | efried | stephenfin: You mean from gerrit or locally? | |
| 14:05:56 | efried | stephenfin: (In either case, I have no idea :) | |
| 14:06:01 | stephenfin | Locally | |
| 14:06:08 | jmlowe | mriedem: tossed out a request for an ask openstack moderator in #openstack, maybe I'll find one | |