| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-14 | |||
| 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 | yep | |
| 14:12:08 | dansmith | oh kay | |
| 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 | |
| 14:17:31 | mriedem | dansmith: you likely need to read the spec to get caught up | |
| 14:17:40 | tssurya | okay I am working on both :D | |
| 14:17:56 | dansmith | mriedem: shame accepted | |