| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-01-19 | |||
| 15:05:28 | gibi | is it so? | |
| 15:06:51 | gibi | OR, does _allocate_mdevs called during reshape itself? | |
| 15:07:16 | gibi | and during reshape you need the conditional | |
| 15:07:38 | gibi | anyhow this is not super important now. We have a tracker, we will get back to this when we have time to clean up | |
| 15:09:45 | bauzas | sorry, was filing the blueprint | |
| 15:09:48 | bauzas | https://blueprints.launchpad.net/nova/+spec/drop-vgpu-reshape-support | |
| 15:10:19 | gibi | thanks! | |
| 15:10:35 | bauzas | yeah, that's correct, the reshape test assumes to create a mdev *before* the reshape | |
| 15:10:45 | bauzas | so we can reshape the allocation | |
| 15:10:53 | bauzas | hence the crazy conditional | |
| 15:11:39 | gibi | OK. so hypotetically we could try to set up the from state purely in DB / placement and only start up the nova-compute service after it. So we won't try to create an mdev with nova in the from state | |
| 15:12:08 | gibi | but I guess it is better use of our time to remove the whole reshape support | |
| 15:12:08 | bauzas | I would need to read the functional test in question but I get your point | |
| 15:12:34 | bauzas | that's actually maybe something to test quickly | |
| 15:12:55 | bauzas | I can write a POC on top of that patch | |
| 15:13:16 | gibi | if you have time :) | |
| 15:13:21 | bauzas | as a FUP, that'd remove the logic and then we could see what exactly to do in the functest | |
| 15:13:46 | bauzas | gibi: I can try to spend a couple of hours on that, I'm pretty done with implementing stuff now | |
| 15:13:58 | bauzas | my left tasks are mostly rebases and reviews | |
| 15:14:07 | bauzas | + the mtty patch | |
| 15:14:52 | bauzas | gibi: thanks for your idea, I'll try it ;) | |
| 15:15:14 | gibi | cool :) | |
| 16:10:54 | bauzas | sean-k-mooney: tbc, you're -1.9999 because of the documentation for https://review.opendev.org/c/openstack/nova/+/845757 ? | |
| 16:12:03 | bauzas | I'm asking for that due to the fact you're OK with the functest https://review.opendev.org/c/openstack/nova/+/845747/3 | |
| 16:12:24 | bauzas | what I could do is try to test with two different custom rcs | |
| 16:12:37 | bauzas | so we could document that this way | |
| 16:24:10 | kashyap | tobias-urdin: Thanks for the respin here: https://review.opendev.org/c/openstack/nova/+/879021. Will look on Mon. (I'm buried in another context now) | |
| 16:40:13 | opendevreview | Sylvain Bauza proposed openstack/nova master: Support multiple allocations for vGPUs https://review.opendev.org/c/openstack/nova/+/845757 | |
| 16:44:34 | bauzas | sean-k-mooney: updated based on your concerns of the portability of group_policy ^ | |
| 16:45:06 | bauzas | I still think we want to document this as this is simpler for operators if they don't give a shit about other nested resource classes | |
| 16:45:34 | bauzas | if you look at the generated docs, they will see a big red warning about using group_policy | |
| 17:08:48 | sean-k-mooney | bauzas: i thikn we shoudl be removing all supprot for group_policy in the flavor | |
| 17:09:33 | sean-k-mooney | and in placement in a new placment microverison | |
| 17:09:49 | sean-k-mooney | isolsate beween sepicifc groups is fine | |
| 17:09:54 | sean-k-mooney | but not how it currently works | |
| 17:14:31 | sean-k-mooney | bauzas: regarding the funtional test i woudl personally prefer if you provided fucntioal tests usign custom resouce classes and/or traits too | |
| 17:14:47 | bauzas | have you seen my new revision ? | |
| 17:15:30 | sean-k-mooney | of the followup patch yes im still -1.999 | |
| 17:15:41 | bauzas | I tend to disagree with you | |
| 17:15:48 | sean-k-mooney | maybe -1.95 you did at least add the other options | |
| 17:16:01 | bauzas | because we have a gap that we need to solve | |
| 17:16:20 | bauzas | I'm just fixing some tech debt where we were only looking at one allocation | |
| 17:16:35 | bauzas | and I'm just documenting ways to alleviate the problem | |
| 17:16:36 | sean-k-mooney | im ok with you documeiting the group_policy way if its not the first way we present adn it not the one we recommend | |
| 17:17:07 | bauzas | the group policy is really the simplest way for ops that don't care about qos-bandwidth or other nested resources | |
| 17:17:28 | bauzas | and there are big warnings in the docs explaining the limitations of that approach | |
| 17:17:37 | sean-k-mooney | sure but that does not mean the shoudl use it even if they dont have those constraits | |
| 17:17:44 | bauzas | so your -1.95 seems very nitpicky honestlyu | |
| 17:17:46 | sean-k-mooney | it the way that will cause them the most upgrade pain | |
| 17:17:55 | sean-k-mooney | would you prefer i put it to -2 then | |
| 17:18:09 | bauzas | putting -2 for docs seems a bit harsh for me | |
| 17:18:19 | bauzas | I can just remove the whole doc | |
| 17:18:22 | sean-k-mooney | its not about the doc | |
| 17:18:24 | bauzas | and leave the patch | |
| 17:18:36 | bauzas | I can even drop the functional test | |
| 17:18:44 | sean-k-mooney | its about recomending somehting that we know will cause upgrade apin in the future | |
| 17:19:11 | sean-k-mooney | the func test is fine | |
| 17:19:18 | bauzas | do you understand that all of your concerns are about the doc file ? | |
| 17:19:25 | bauzas | not about the python module? | |
| 17:19:51 | bauzas | like I said, I can just drop the doc and leave ops find the way they prefer by themselves | |
| 17:19:58 | sean-k-mooney | so i think it woudl be nice ot have other func test as well but you have enocuh to merge the patch i think | |
| 17:20:02 | sean-k-mooney | so yes its all about the doc | |
| 17:20:14 | bauzas | so, I'll split the patch | |
| 17:20:30 | bauzas | I'll just address the python fix in one change | |
| 17:20:43 | sean-k-mooney | no | |
| 17:20:43 | bauzas | and we'll discuss the docs things in a separate change | |
| 17:20:47 | sean-k-mooney | please keep it in two | |
| 17:20:57 | sean-k-mooney | you can add a thid for the doc if you like | |
| 17:21:04 | bauzas | that's what I'm suggesting | |
| 17:21:07 | bauzas | 1/ functest | |
| 17:21:08 | sean-k-mooney | but im just askign you to swap 20 lins of docs | |
| 17:21:09 | bauzas | 2/ patch | |
| 17:21:11 | bauzas | 3/ doc | |
| 17:21:44 | bauzas | so your concern is about the future and the fact that we persist flavors right? | |
| 17:21:56 | sean-k-mooney | yes | |
| 17:22:02 | bauzas | I'm just trying to understand the concern correctly | |
| 17:22:19 | bauzas | say one day another great feature would provide other nested RPs | |
| 17:22:29 | bauzas | and ops eagerly wanting it | |
| 17:22:42 | sean-k-mooney | yep | |
| 17:22:58 | sean-k-mooney | or endusers | |
| 17:23:01 | bauzas | those new children would be one separate RPs but the GPU ones, right? | |
| 17:23:03 | sean-k-mooney | it might not be the operator | |
| 17:23:12 | sean-k-mooney | that not the issue | |
| 17:23:29 | sean-k-mooney | if we use isolate you cant have 2 request_groups form the same rp | |
| 17:23:41 | sean-k-mooney | so pci in placment for example | |
| 17:23:50 | sean-k-mooney | you wont be abel to have 2 vfs form teh same hsot nic | |
| 17:24:00 | bauzas | I get it | |
| 17:24:11 | bauzas | isolate applies to all resource groups | |
| 17:24:15 | sean-k-mooney | yep | |
| 17:24:26 | bauzas | so the problem is really with prefilters then ? | |
| 17:24:32 | sean-k-mooney | no | |
| 17:24:36 | bauzas | because the flavors wouldn't express those | |
| 17:24:58 | bauzas | pci in placement is a good strawman, let's continue to use it for the example | |
| 17:25:00 | sean-k-mooney | the problem is with the placment api | |
| 17:25:19 | sean-k-mooney | well it also apples to cyborg or neturon prots with resouce requests | |
| 17:25:31 | bauzas | say I have VGPUS and PCI | |
| 17:25:43 | sean-k-mooney | sure | |
| 17:25:47 | bauzas | the problem arises when I want to ask for both, right? | |
| 17:25:54 | sean-k-mooney | yes | |
| 17:26:07 | bauzas | and what if I'm asking for a single resource ? | |