| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-01-29 | |||
| 19:10:21 | efried | eandersson: can you write me a flavor example with two numa nodes where one has small pages and one has large? | |
| 19:10:34 | efried | whoops, eandersson disregard. ^ was for sean-k-mooney | |
| 19:10:38 | sean-k-mooney | no | |
| 19:10:44 | sean-k-mooney | pagesize is vm wide | |
| 19:10:47 | efried | (my IRC client has been dropping the first char of my messages lately) | |
| 19:11:00 | efried | okay, fine, can you write me a flavor with two numa nodes and an explicit page size? | |
| 19:11:24 | sean-k-mooney | yes ill add 2 | |
| 19:11:31 | efried | (turns out 'sean<tab>' minus the first character is 'ean<tab>') | |
| 19:12:35 | sean-k-mooney | hehe ill remove our disscution on the first example to clean up the description | |
| 19:16:43 | sean-k-mooney | you can also split the cpu asemetircly but that is overkill for the exampels i think | |
| 19:17:27 | sean-k-mooney | for the implict splitign its an error if the cpus and ram and not evenly devisable by the number of numa nodes | |
| 19:19:16 | efried | sean-k-mooney: I prefer leaving that third example as it was before, since it shows that we could land on either of the LARGE RPs. | |
| 19:19:25 | efried | ++ | |
| 19:19:25 | sean-k-mooney | ya | |
| 19:19:30 | sean-k-mooney | that is why i reverted it | |
| 19:19:47 | sean-k-mooney | any why i used large in the first place | |
| 19:19:59 | efried | sean-k-mooney: any other examples that we should throw in? | |
| 19:20:11 | sean-k-mooney | am maybe a non numa guests | |
| 19:20:58 | efried | yeah | |
| 19:21:17 | efried | to show that it would not land on the sample host at all. | |
| 19:22:28 | sean-k-mooney | yes | |
| 19:22:37 | sean-k-mooney | i was trying to figure out the not num host | |
| 19:22:40 | sean-k-mooney | *numa | |
| 19:23:44 | sean-k-mooney | if we did not add the forbiden trait | |
| 19:23:49 | sean-k-mooney | then it could actully land on that host | |
| 19:24:00 | sean-k-mooney | but we would have to pin it to a numa node | |
| 19:24:13 | sean-k-mooney | which we could do but we proably dont want too | |
| 19:24:28 | sean-k-mooney | so you can continue to create vms that span numa nodes if you dont care | |
| 19:24:30 | efried | right, that's what I was implying earlier when I said we could probably overlap, but should prevent that for now | |
| 19:24:40 | efried | oh, that wouldn't allow you to span numa nodes. | |
| 19:24:40 | sean-k-mooney | ya | |
| 19:24:52 | sean-k-mooney | ya it would not you are right | |
| 19:24:56 | efried | oh, I see, you mean your proc from one and your mem from another | |
| 19:24:57 | sean-k-mooney | not without can split | |
| 19:25:20 | sean-k-mooney | you could have procs and memory span ya | |
| 19:25:33 | sean-k-mooney | but can_split would be need to have any one resouce span numa nodes | |
| 19:25:42 | efried | yeah, actually, the non-NUMA example can be simplified if we just use a granular group for the proc & mem.... | |
| 19:26:01 | sean-k-mooney | ya | |
| 19:26:04 | sean-k-mooney | that would work | |
| 19:26:32 | efried | simpler, I like. | |
| 19:26:36 | sean-k-mooney | oh we are missign something from all of them | |
| 19:26:44 | sean-k-mooney | we need to add group_policy=none | |
| 19:26:58 | sean-k-mooney | because we are using granular groups | |
| 19:27:58 | sean-k-mooney | we still get the correct affintiy because fo same tree in the multi numa case | |
| 19:28:09 | sean-k-mooney | even with group_policy=none | |
| 19:28:56 | efried | yeah, I was just going to check whether we in fact did remove group_policy in the latest microversions. | |
| 19:29:16 | efried | it's irrelevant in this case. We get the same result with isolate or none | |
| 19:29:21 | sean-k-mooney | looking at the api doces its still there | |
| 19:29:35 | efried | okay, boo. But as noted above, it's irrelevant, so set it to whatever. Do you agree? | |
| 19:29:56 | sean-k-mooney | it can be in this case | |
| 19:30:03 | sean-k-mooney | but isolate breaks eaisly | |
| 19:30:15 | sean-k-mooney | for example 2 port with bandwith requests | |
| 19:30:23 | sean-k-mooney | so i dont like publicising its use | |
| 19:30:43 | efried | Right, so the point is, we can leave it to the user and/or the bandwidth code to decide on group_policy. | |
| 19:30:52 | sean-k-mooney | yes | |
| 19:30:57 | efried | IIRC the bandwidth code is defaulting it rn. | |
| 19:31:07 | efried | or at least we talked about doing that. | |
| 19:31:07 | efried | We can ask gibi to confirm | |
| 19:31:16 | sean-k-mooney | rn as in none? | |
| 19:31:31 | efried | 'right now' | |
| 19:31:47 | sean-k-mooney | oh i think its defaultin to none if it is | |
| 19:31:56 | sean-k-mooney | that should be our default unless you say otherwise | |
| 19:32:25 | sean-k-mooney | ok so it required becasuee we are using groups but the value is not relevent to the spec | |
| 19:32:30 | sean-k-mooney | im fine with that | |
| 19:32:39 | sean-k-mooney | its an implemenation detail | |
| 19:33:18 | efried | yeah. That was a gripe I had during the nested magic design, that group_policy should default (can't remember which way I said) at this point because we can control everything we need using other, more granular (heh) mechanisms. | |
| 19:33:24 | efried | but we didn't actually do that. | |
| 19:33:33 | efried | And, confirmed, we're defaulting to 'none' these days. | |
| 19:33:43 | efried | I found the reno yaml, lemme find where it is in the docs. | |
| 19:34:10 | sean-k-mooney | well really we should not have it be global either | |
| 19:34:21 | sean-k-mooney | it should be per set of groups or per subtreee or something | |
| 19:34:27 | efried | https://docs.openstack.org/releasenotes/nova/train.html#other-notes | |
| 19:34:28 | sean-k-mooney | anyway out of scope | |
| 19:35:04 | efried | right, that was my gripe. We now have same_subtree to dictate which can be shared and which can be spread. Because same_subtree also devolves to same rp in relevant cases. | |
| 19:35:34 | sean-k-mooney | ya | |
| 19:36:12 | sean-k-mooney | provide we model nics with an RP per PF same_subtree or the negation should hanel that too | |
| 19:36:37 | sean-k-mooney | so we might be able to remvoe the group polices thing at some point | |
| 19:37:04 | sean-k-mooney | anyway if this does not require it to make it work it makes me happy | |
| 19:40:15 | sean-k-mooney | i have saved a copy of that etherpad locally just in case by the way. | |
| 19:41:07 | efried | cool. I've got my comment all composed, will post it when I'm done reviewing the rest. Hopefully bauzas will parlay the etherpad into the doc before the etherpad goes kablooey, as it inevitably will. | |
| 19:41:38 | sean-k-mooney | well we nerver delete them | |
| 19:41:48 | sean-k-mooney | the only go away if the db gets currpted | |
| 19:42:04 | sean-k-mooney | so you would be suprised how long they survie | |
| 19:42:20 | sean-k-mooney | that said we have been bitten enough times at ptgs that i make backups | |
| 19:42:22 | efried | I've seen enough corrupted | |
| 19:42:23 | efried | yeah. | |
| 20:15:25 | artom | dansmith, around? So, are you completely opposed to https://review.opendev.org/#/c/672595/61/nova/tests/unit/virt/libvirt/fakelibvirt.py@489 ? | |
| 20:16:06 | artom | Because I've been trying to write something better, and I'm not sure what I have is worth it. Maybe I just suck, or am overthinking it? | |
| 20:16:30 | dansmith | Why is [1] harder than 1? Aside from all the test change | |
| 20:17:08 | dansmith | or maybe you're stuck on the fact that it really should be named cpu_socket_map or something? | |
| 20:17:27 | dansmith | I do think what you have is pretty ugly and would prefer a mutually exclusive additional arg to what you have It hink | |
| 20:17:52 | artom | dansmith, well, the way I have it now is a full-on separate class | |
| 20:18:01 | artom | Well, classes, because it trickles up and down | |
| 20:18:06 | artom | Now = locally, not pushed yet | |
| 20:18:53 | dansmith | and that's really just for tests? | |
| 20:19:24 | artom | The objective being, allow tests that don't need the sockets maps complexity to use the existing class, and have a new one for the tests that need it | |
| 20:19:33 | artom | Instead of imposing sockets map on all tests | |
| 20:20:03 | artom | You mean the HostInfo and NUMATopology classes? Yeah, just for tests | |
| 20:20:08 | dansmith | Right, point is you've created a new class to wrap hostinfo just for tests | |
| 20:20:19 | dansmith | seems kinda smelly since they're not doing what the production code does | |