| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-14 | |||
| 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 | |
| 14:06:10 | efried | stephenfin: If it's a *testr thing, mtreinish would be the SME I would call on. | |
| 14:06:13 | stephenfin | darn, where's mtreinish when you need him | |
| 14:06:16 | stephenfin | jinx | |
| 14:11:16 | mriedem | dansmith: see my comment on this pike backport for the build failure weigher - we'll need to handle the ironic host manager fallout there somehow https://review.openstack.org/#/c/573248/ | |
| 14:11:41 | dansmith | mriedem: we already merged something for that | |
| 14:12:02 | mriedem | i know, on queens | |
| 14:12:03 | dansmith | mriedem: https://review.openstack.org/#/c/574997/ | |
| 14:12:06 | mriedem | we just have to do the dance for pike | |
| 14:12:08 | dansmith | oh kay | |
| 14:12:08 | dansmith | yep | |
| 14:15:16 | mriedem | tssurya: we can also be fixing the instance list 500 error as a bug fix today | |
| 14:15:23 | mriedem | regardless of the handling a down cell spec | |
| 14:15:42 | mriedem | tssurya: if you haven't started a fix for that, maybe dansmith wants to take a crack at it? | |
| 14:16:13 | tssurya | mriedem: you mean this one ? -> https://bugs.launchpad.net/nova/+bug/1773945 | |
| 14:16:14 | openstack | Launchpad bug 1773945 in OpenStack Compute (nova) "nova client servers.list crashes with bad marker" [Medium,Triaged] - Assigned to Surya Seetharaman (tssurya) | |
| 14:16:48 | tssurya | or the general one as a part of handling down cell | |
| 14:16:49 | mriedem | tssurya: no | |
| 14:16:52 | mriedem | the general one | |
| 14:17:02 | dansmith | I'm confused, isn't tssurya working on the general one? | |
| 14:17:03 | mriedem | tssurya: if you don't have a patch for that ^ bug about the marker, i can push something for that | |
| 14:17:22 | mriedem | she's working on the handling a down cell alternative i thought | |
| 14:17:24 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add notification support for trusted_certs https://review.openstack.org/563269 | |
| 14:17:25 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add certificate validation docs https://review.openstack.org/560158 | |
| 14:17:26 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: WIP: Add trusted certs to feature support matrix docs https://review.openstack.org/574890 | |
| 14:17:27 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Remove max_size parameter from fake_libvirt_utils.fetch_*image methods https://review.openstack.org/574911 | |