| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-12 | |||
| 11:05:57 | sean-k-mooney | efried: is it causing issues | |
| 11:05:58 | efried | I'll save you reading the backscroll, but we're doing something different now: we're going to do both GET /a_c calls up front (with a workaround conf opt) | |
| 11:06:13 | efried | Stephen is working on that now | |
| 11:06:21 | sean-k-mooney | ok | |
| 11:06:28 | sean-k-mooney | what is the advantage of that | |
| 11:06:49 | sean-k-mooney | are we doing them in parallel or something | |
| 11:06:57 | efried | with the cascaded approach, if we did the first one, got results, then sent them down to the filter and the filter rejected all of them, we'd be hosed. | |
| 11:07:15 | efried | So one option was to make that retry "wider" | |
| 11:07:22 | efried | which would be tough to code | |
| 11:07:40 | artom | efried, has that configparser thing been fixed? I see you rechecked the NUMA LM patches | |
| 11:07:44 | sean-k-mooney | ok i see | |
| 11:07:47 | efried | artom: yes | |
| 11:07:52 | artom | Sweet | |
| 11:07:54 | efried | artom: carefully curating the gate atm | |
| 11:08:04 | artom | Yep, thanks for that | |
| 11:08:04 | efried | sean-k-mooney: no, we have to do them sequentially, because we always want to try the pcpu ones first for a given host. | |
| 11:08:28 | efried | but we do one right after the other | |
| 11:08:35 | efried | and collect all the candidates | |
| 11:08:41 | efried | then send them all down to the filter. | |
| 11:08:58 | sean-k-mooney | right | |
| 11:09:24 | sean-k-mooney | i assume we only add host form the second query if its not in the first? | |
| 11:09:36 | sean-k-mooney | or do we just let the filter handel that | |
| 11:09:41 | efried | I don't think we're being that careful about it | |
| 11:09:51 | sean-k-mooney | actully it does not matter | |
| 11:09:54 | efried | right | |
| 11:10:19 | sean-k-mooney | the filter work on host not allocation candiates | |
| 11:11:01 | sean-k-mooney | so it will pass the host if it fit and fail it if it does not | |
| 11:11:23 | sean-k-mooney | and the host will only support one of the two with pinning | |
| 11:12:15 | sean-k-mooney | a host can have VCPU and PCPUs but if it returns pcpu allocation then that is what we will need to use | |
| 11:14:42 | sean-k-mooney | efried: by the way this https://review.opendev.org/#/c/679656/ is the numa live migration job. it not a pirortiy today but i would like to merge that before RC1 to get it running nightly once artoms code is fully merged. | |
| 11:15:04 | sean-k-mooney | it add the nova-nfv-multi-numa-multinode job | |
| 11:15:16 | efried | sean-k-mooney: ack, please ask about it next week | |
| 11:15:33 | sean-k-mooney | yep will do | |
| 11:16:45 | efried | sean-k-mooney: https://review.opendev.org/#/c/681358/ os-vif release ack pls? | |
| 11:17:01 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Do not query allocations twice in finish_revert_resize https://review.opendev.org/678827 | |
| 11:17:09 | sean-k-mooney | mels patch ya ill ack that now | |
| 11:20:04 | openstackgerrit | Stephen Finucane proposed openstack/nova master: fixup! Add support for translating CPU policy extra specs, image meta https://review.opendev.org/681719 | |
| 11:20:29 | stephenfin | efried, sean-k-mooney, alex_xu, bauzas: Before I squash that back and fix the tests, want to give that the once over ^ ? | |
| 11:20:55 | alex_xu | yup, checking now | |
| 11:21:09 | efried | ... | |
| 11:25:02 | alex_xu | ah, that is smart | |
| 11:26:00 | alex_xu | stephenfin: works for me | |
| 11:26:43 | sean-k-mooney | checking | |
| 11:27:01 | efried | stephenfin: looks good, couple of comments in there. | |
| 11:29:58 | luyao | sean-k-mooney: Hi, if you get time, could you help look vpmem xml again? thanks ( we discussed before about the numa requiring and alignment, and got a consensus about them) | |
| 11:30:29 | luyao | https://review.opendev.org/#/c/678455/ | |
| 11:31:51 | sean-k-mooney | efried: also commented. we should not use update as i noted inline | |
| 11:32:22 | stephenfin | efried: I shouldn't have pushed those mox patches through last night either. Sorry :( | |
| 11:32:42 | efried | no biggie stephenfin | |
| 11:33:00 | efried | they're all going to get kicked out here in a minute | |
| 11:33:05 | sean-k-mooney | luyao: yep i have it open efried pinged me earlier | |
| 11:33:29 | sean-k-mooney | im just going to grab coffe then ill review the vpmem seriese in full starting with the xml patch | |
| 11:33:31 | stephenfin | cool. I switched to -2 on the bottom one to make it clear | |
| 11:33:36 | luyao | sean-k-mooney: hah, thanks | |
| 11:35:00 | stephenfin | On the other hand, once that lands mox is basically gone. It's only been four years \o/ | |
| 11:35:19 | efried | sean-k-mooney, stephenfin: It's not important enough to spend a bunch of time on, but am I crazy about .update()? | |
| 11:35:38 | stephenfin | in relation to...? | |
| 11:35:42 | efried | a psum is a psum | |
| 11:36:16 | efried | the way you're doing it I guess you're not replacing one that's already there, whereas .update would (redundantly) replace | |
| 11:36:33 | stephenfin | I need a link | |
| 11:36:45 | efried | I guess python probably isn't smart enough to skip | |
| 11:36:48 | sean-k-mooney | oh maybe i miss understood | |
| 11:36:52 | efried | so yeah, I guess the way you're doing it is going to be more efficient | |
| 11:36:56 | efried | but the result will be the same | |
| 11:37:01 | sean-k-mooney | i though stephen was filtering the allocation candiate but he is not | |
| 11:37:10 | efried | just question of whether you want fewer LOC I guess | |
| 11:37:23 | efried | stephenfin: https://review.opendev.org/#/c/681719/1/nova/scheduler/manager.py@197 | |
| 11:37:30 | sean-k-mooney | update is fine for the summaries | |
| 11:37:51 | sean-k-mooney | i would prefer if we filtered this however | |
| 11:37:53 | sean-k-mooney | Draft | |
| 11:38:17 | sean-k-mooney | alloc_reqs.extend(alloc_reqs_fallback) | |
| 11:38:45 | efried | sean-k-mooney: filter it how? | |
| 11:38:59 | stephenfin | efried: tomato tomato. As you say, it doesn't matter | |
| 11:39:07 | stephenfin | I'm happy to go with '.update()' | |
| 11:39:10 | sean-k-mooney | is that the set of alloction candiates | |
| 11:39:13 | efried | we explicitly can't skip the ones we already have PCPUs for | |
| 11:39:20 | efried | that's the whole point | |
| 11:39:35 | efried | ... I think | |
| 11:39:42 | sean-k-mooney | it would be better not to pass 2 allcoation candiate for any given host | |
| 11:39:49 | efried | because the filter might kick out the PCPU ones | |
| 11:40:18 | sean-k-mooney | efried: we need to make sure if the filter passes we use the PCPU allocation candiate not the VCPU one | |
| 11:40:28 | sean-k-mooney | if we have two we need extra code to handel that | |
| 11:40:37 | efried | That's already covered I thought | |
| 11:40:43 | efried | because the candidates are in order per host | |
| 11:40:43 | sean-k-mooney | where | |
| 11:41:06 | efried | .extend is O(1) (I think) so we're just taking a mem hit by not filtering. Whereas if we loop through and try to filter, we're O(N). | |
| 11:41:07 | sean-k-mooney | if they are ordered and we take the first one then ok | |
| 11:41:11 | efried | y | |
| 11:41:24 | efried | we noodled this out with gibi earlier I think | |
| 11:41:27 | stephenfin | To do that, we'd need to inspect each entry in alloc_reqs_fallback, pull out the resource provider ID, and check if it exists in alloc_reqs | |
| 11:41:34 | stephenfin | and I think they're ordered so it won't matter | |
| 11:41:53 | sean-k-mooney | efried: exthend is fine if we have odering and can rely on it | |
| 11:42:11 | sean-k-mooney | i just was not aware that was a thing | |
| 11:42:16 | stephenfin | I could do this (I think) | |
| 11:42:35 | efried | stephenfin: I'd rather leave it I think | |
| 11:42:47 | sean-k-mooney | ya i think its fine | |
| 11:42:51 | efried | unless some good reason to do otherwise | |
| 11:42:52 | stephenfin | alloc_reqs.extend([a for a in alloc_reqs_fallback if a['allocations'][path to rp UUID] not in provider_summaries) | |
| 11:43:17 | efried | still O(N) | |
| 11:43:20 | sean-k-mooney | im just trying to make sure we dont pick the wrong allcoatin candiage and end up using VCPUs when we have pinned cores on a host that has both | |