| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-01-19 | |||
| 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. | |
| 17:29:53 | bauzas | (well, I can add the mention to computecapabilitiesFilter for sure) | |
| 17:30:04 | sean-k-mooney | and neutron QOS prots and cyborg integration if the cyborg request profile has multiple devices | |
| 17:30:16 | bauzas | that's covered by the warning section | |
| 17:30:43 | sean-k-mooney | can you see why an approch that break 5 differnt feature is not something i want to recomemnd people to use as the first option | |
| 17:30:45 | bauzas | I'm ready to bet that a very small fraction of users and ops don't care a bit about any of those stuff | |
| 17:31:20 | sean-k-mooney | sure so we can docuemnt it for them but not the first way we recomemnd | |
| 17:31:40 | bauzas | this isn't breaking the feature, this is a limitation saying "you can't and shouldn't request multiple vgpus per instance if you want to create a flavor that asks for more than vgpus" | |
| 17:31:57 | sean-k-mooney | all im asking you to do is move lines 132-156 after lines 158-181 | |
| 17:32:04 | bauzas | if you really want to mix resources, do other ways | |
| 17:32:16 | bauzas | let's talk about the alternatives | |
| 17:32:19 | bauzas | custom traits | |
| 17:32:54 | bauzas | what you're proposing requires ops to define distinct traits between GPUs | |
| 17:33:00 | bauzas | even if they share the same type | |
| 17:33:31 | bauzas | the only difference would be "I'm GPU A" while the other would be "I'm GPU B" | |
| 17:33:46 | bauzas | that's not great, right? | |