| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-01-19 | |||
| 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 | bauzas | and we'll discuss the docs things in a separate change | |
| 17:20:43 | sean-k-mooney | no | |
| 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 ? | |
| 17:26:24 | bauzas | (resource *class) | |
| 17:26:33 | sean-k-mooney | yes | |
| 17:27:05 | sean-k-mooney | so pci in placeemnt is a less good exampel because we dont suppot that with neturon port yet. but ill give you an example | |
| 17:27:08 | bauzas | you agree that's not a problem if I'm only asking for VGPU *or* PCI, right ? | |
| 17:27:26 | sean-k-mooney | openstack flavor set vgpu_2 --property "resources1:VGPU=1" \ | |
| 17:27:28 | sean-k-mooney | --property "resources2:VGPU=1" \ | |
| 17:27:30 | sean-k-mooney | --property "group_policy=isolate" | |
| 17:28:07 | sean-k-mooney | if we add --property "hw:pci_ailias=my_vf:2" | |
| 17:28:36 | sean-k-mooney | then if we only have one defivce with my_vf aviaable | |
| 17:28:45 | bauzas | I got it | |
| 17:28:48 | sean-k-mooney | then isolate will break that | |
| 17:28:48 | bauzas | hence my warning | |
| 17:28:50 | bauzas | .. warning:: Be careful when using ``group_policy`` as this policy is global to all the resources request. If you ask for other resources but only VGPUs in your flavor, that ``isolate`` policy will also apply for other | |
| 17:28:52 | bauzas | ResourceProviders. | |
| 17:29:08 | bauzas | that will be written in solid red | |
| 17:29:26 | sean-k-mooney | and it also breadk AggregateInstanceExtraSpecsFilter and computecapaitlies filter | |
| 17:29:33 | bauzas | written too | |
| 17:29:37 | bauzas | .. note:: If you use ``AggregateInstanceExtraSpecsFilter`` filter, you also need to configure your aggregates metadata with the ``group_policy`` values. | |