| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-23 | |||
| 12:54:05 | bauzas | or, using another RCs | |
| 12:54:16 | sean-k-mooney | we proposed having provider type before the trait idea | |
| 12:54:17 | bauzas | that's the alternative | |
| 12:54:37 | sean-k-mooney | the only reason we went with the trait was peopel did not want to do the work to extend placment to model that | |
| 12:54:47 | bauzas | sean-k-mooney: this was 3 years ago, right? | |
| 12:55:01 | bauzas | sean-k-mooney: and people weren't thinking not only about cyborg, right? | |
| 12:55:03 | sean-k-mooney | when it was first propsoed yes | |
| 12:55:17 | sean-k-mooney | but it cam up at the ptg sicne | |
| 12:55:20 | gibi | I think we tend to mix provider type with consumer type, the latter is what was discussed in placement | |
| 12:55:46 | bauzas | I'm pretty sure that if cinder was asking to use the same RCs, then we would think about other alternatives than owner traits... | |
| 12:55:48 | sean-k-mooney | gibi: no we have discussed both | |
| 12:56:10 | bauzas | but here, see | |
| 12:56:13 | sean-k-mooney | owner triats was inteded to be a version fo provider types that did not reuqire placment code chagnes | |
| 12:56:28 | bauzas | for me, if cinder wants to support some RCs, those would be like oranges | |
| 12:56:35 | bauzas | while nova looks at apples | |
| 12:56:47 | sean-k-mooney | then we shoudl get rid of the idea of standtar resouce classes | |
| 12:56:54 | sean-k-mooney | they have 0 value if they cannot be shared | |
| 12:57:06 | sean-k-mooney | in fact they have negitive value | |
| 12:57:34 | gibi | sean-k-mooney: standard means you predefine them and therefore easily standardize them in the flavor extraspec too | |
| 12:58:20 | sean-k-mooney | that is not how i view them | |
| 12:58:42 | sean-k-mooney | if standarising them does not bring interoperatbltiy then we can just standarise them in the code of the project that uses them | |
| 12:58:49 | sean-k-mooney | without needing a lib to do that | |
| 12:59:35 | sean-k-mooney | the project could simple have registered there "standard" resocue classes when they first connect to placment and we could have even namespacee them as the owner if we wanted too | |
| 13:00:01 | gibi | sean-k-mooney: you are right I withdraw my the above :) | |
| 13:00:18 | gibi | os-resource-classes for shering | |
| 13:00:20 | gibi | sharing | |
| 13:01:11 | sean-k-mooney | so we have a few optiops, we can proceed with new "standard" maybe "shared" is better resocues classes for cyborg devices | |
| 13:01:13 | gibi | but sharing does not make too much sense. At least a disk_gb in cinder backend and a disk_gb in nova local storage are not interchangeable | |
| 13:01:27 | sean-k-mooney | we can use the same with some other owner mechanium | |
| 13:01:36 | sean-k-mooney | or we could use custom resouce classes right | |
| 13:01:59 | sean-k-mooney | gibi: sharing requires ownership of the resouce | |
| 13:02:13 | gibi | doesn't sharing means we share ownership? | |
| 13:02:14 | bauzas | sharing vs. sharding | |
| 13:02:20 | bauzas | we discussed this yesterday | |
| 13:02:44 | sean-k-mooney | gibi: no it means to sue it multiple service both mush supprot tracking the ownwership in placment vai some mechanium | |
| 13:03:02 | bauzas | gibi: agreed on the sharing ownership | |
| 13:03:15 | gibi | sharing an RC via os-resource-classes only make sense to me if there are two services and both managing that RC and that RC represents an interchangeable resource regardless of which serivice is reported it | |
| 13:03:25 | bauzas | gibi: if the conductor gets some allocation from a shared resource, it should pass the allocation to the right service | |
| 13:03:41 | sean-k-mooney | gibi: to me that is not what that means | |
| 13:04:13 | stephenfin | Python 3.10 looks pretty sweet. It'll be fun to use that in 5 years or whatever :-D https://lwn.net/Articles/860389/ | |
| 13:04:18 | sean-k-mooney | todate we dodn thave any service that share a common resouce class because we have not modeled ownwersyhip yet | |
| 13:04:39 | bauzas | sean-k-mooney: we don't need to model ownership for shared resources | |
| 13:04:43 | sean-k-mooney | stephenfin: it has some nice things yest like that swtich statement based on patern matchin | |
| 13:04:55 | sean-k-mooney | stephenfin: we should be able to bump our min python to 3.8 soon | |
| 13:04:56 | bauzas | if we have same resources, this is conceptually the same | |
| 13:05:10 | opendevreview | Rodolfo Alonso proposed openstack/os-vif master: Make explicit the network backend used in the CI jobs https://review.opendev.org/c/openstack/os-vif/+/797640 | |
| 13:05:18 | sean-k-mooney | stephenfin: im hoping that 3.8 bump happens next cycle | |
| 13:05:31 | bauzas | you're asking for apples, whether they are provided by a grocery or by something else | |
| 13:05:43 | sean-k-mooney | bauzas: what makes a cyborg vgpu different form a nova one | |
| 13:05:44 | opendevreview | Rodolfo Alonso proposed openstack/nova master: Make explicit the network backend used in the CI jobs https://review.opendev.org/c/openstack/nova/+/797641 | |
| 13:06:06 | sean-k-mooney | they are identical | |
| 13:06:10 | bauzas | sean-k-mooney: if you're asking for a resource that's not the same than an apple, this is not an apple | |
| 13:06:11 | sean-k-mooney | form a user persective | |
| 13:06:41 | bauzas | the user sees flavors | |
| 13:06:49 | sean-k-mooney | not in all cases | |
| 13:06:52 | bauzas | he doesn't see resources | |
| 13:07:02 | sean-k-mooney | the extra specs are not alwasy visable to users | |
| 13:07:13 | bauzas | I'm done with our "power users" | |
| 13:07:14 | sean-k-mooney | in fact they might not be visable by default that is contoled by policy | |
| 13:07:45 | bauzas | sean-k-mooney: but with cyborg, they don't see VGPUs when looking at the flavors, right? | |
| 13:08:02 | sean-k-mooney | both are stored in the flavor as an extra spec | |
| 13:08:04 | bauzas | they see device profiles, right? | |
| 13:08:16 | sean-k-mooney | e.g. resouce:vgpu or device-profile=whatever | |
| 13:08:17 | bauzas | this is like ironic | |
| 13:08:29 | sean-k-mooney | or pci_ailais=my-gpu | |
| 13:08:48 | bauzas | resource:vgpu=1 is only a nova syntax for nova-managed vgpus, right? | |
| 13:08:59 | gibi | flavors with resource:vgpu and flavors with device-profile could be interchangeable from the user perspective if he gets a VM with vGPU passed through in both case | |
| 13:09:01 | bauzas | in the flavor, I mean | |
| 13:09:28 | bauzas | gibi: you're mentioning a mixed usecase | |
| 13:09:32 | sean-k-mooney | bauzas: kind of yes. you could use the sriov based vgpus with pci passthough alias but for mdevs yes | |
| 13:09:45 | bauzas | gibi: where users don't care whether vgpus are offered by nova or cyborg | |
| 13:09:51 | gibi | bauzas: sort of yes | |
| 13:10:00 | sean-k-mooney | bauzas: yes but 99% they wont | |
| 13:10:01 | gibi | bauzas: I want to figure out which resource is interchangeable | |
| 13:10:10 | sean-k-mooney | cyborg is an mostly admin only api | |
| 13:10:25 | sean-k-mooney | so normally user wont interact with it | |
| 13:10:32 | bauzas | I think we're boiling the ocean and we need to babystep | |
| 13:10:52 | bauzas | *for the moment* cyborg flavors are using device profiles, right? | |
| 13:10:57 | sean-k-mooney | yes | |
| 13:11:11 | gibi | bauzas: we are struging here as we i) want a baby step but ii) doen't want to create a wrong precedence | |
| 13:11:15 | bauzas | ok, so they're conceptually different from nova | |
| 13:11:20 | gibi | precedent | |
| 13:11:26 | bauzas | gibi: agreed | |
| 13:11:37 | bauzas | gibi: that's why I dislike owner traits tbh | |
| 13:11:55 | bauzas | this looks to me an horrible hack for a single purpose | |
| 13:12:01 | sean-k-mooney | its not | |
| 13:12:23 | bauzas | sean-k-mooney: this is a hack, because this requires to touch the current modeling we have | |
| 13:12:24 | gibi | if we go with separate RC now, then we probably copy that for accelerator_direct + PCI in placement, and for disk_gb for cinder + nova too | |
| 13:12:37 | sean-k-mooney | i spent weeks tryign to come up with another way and that was the only way i coudl get jhone and other to consier moving ti forward | |
| 13:12:45 | gibi | and then I agree with sean that os-resource-classes has no use | |
| 13:12:45 | bauzas | gibi: we can make a consensu | |
| 13:13:00 | bauzas | gibi: or a statement if you prefer | |
| 13:13:08 | sean-k-mooney | bauzas: the current modeling does not fit our needs | |
| 13:13:30 | bauzas | gibi: if you have requirements for scheduling decisions that require your resources to be shared, you have to use other RCs | |
| 13:13:38 | bauzas | sharded* | |
| 13:13:45 | bauzas | and absolutely not shared | |
| 13:14:46 | bauzas | gibi: but if you are OK with having scheduling decisions that accept to mix your resources with other resources, then eventually the conductor (or the scheduling client rather) has to place the request to the right service | |
| 13:15:41 | sean-k-mooney | bauzas: we can supprot that but its a lot more work for the cyborg team | |
| 13:15:47 | gibi | bauzas: I think the scheduling decision can be made independently from the service providing the resources, the consumption of the resources on the hypervisor needs the information which service tracks the phyisical resource | |
| 13:15:49 | sean-k-mooney | are you willing to help them do that correctly | |