| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-23 | |||
| 12:50:10 | sean-k-mooney | swp20: you are using a function that was removed in 1.4 it was deprecated around 0.9 you shoudl jsut use the replacemnt funciton | |
| 12:50:48 | sean-k-mooney | gibi: yes its the first time since cinder did not modle anything in placment yet | |
| 12:51:00 | sean-k-mooney | we would have the same issue with disk_GB | |
| 12:51:31 | gibi | and we will have the same issue with VFs one we have smartnic in cyborg and PCI devices in placement | |
| 12:51:37 | gibi | once | |
| 12:52:50 | bauzas | sean-k-mooney: gibi: that's why I think we should maybe think about some kind of provider type | |
| 12:53:18 | bauzas | we couldn't just use traits for owners | |
| 12:53:39 | bauzas | or this would mean that we would have traits for all of the resources we currently have | |
| 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 | bauzas | gibi: we can make a consensu | |
| 13:12:45 | gibi | and then I agree with sean that os-resource-classes has no use | |
| 13:13:00 | bauzas | gibi: or a statement if you prefer | |