| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-23 | |||
| 12:36:12 | sean-k-mooney | so cyborg shoudl be updated to supprot 1.4 | |
| 12:36:23 | sean-k-mooney | in doing so your minium requiredm will incerease to 1.2 | |
| 12:36:40 | sean-k-mooney | for the Query.with_for_update method | |
| 12:36:58 | sean-k-mooney | actuly no | |
| 12:37:03 | sean-k-mooney | it was added in 0.9 | |
| 12:37:17 | sean-k-mooney | swp20: so you dont have to udpated your requiremetn.txt in cyborg | |
| 12:38:46 | gibi | bauzas, sean-k-mooney: yeah I think in this specific case we need to allow both service to manage vgpus and in this specific case it is a lot simpler and cleaner to have separate RCs. | |
| 12:39:25 | gibi | sean-k-mooney: for the cinder case. I think the different there is tha cinder's disk_gb is not consumable by nova but consumable by the cinder backned. And this consumability needs to be modelled | |
| 12:39:47 | sean-k-mooney | what about for generic VFs and PFs for neutron sriov | |
| 12:40:07 | sean-k-mooney | because there is work to support cyboprg mandaged sriov vfs also | |
| 12:40:07 | gibi | good point | |
| 12:40:20 | sean-k-mooney | that are assocated with a nutorn port | |
| 12:40:43 | sean-k-mooney | we can use a differet resouce class there too | |
| 12:41:05 | sean-k-mooney | but this pattern has many implications if we repeat it | |
| 12:41:05 | bauzas | again, same thoughts here | |
| 12:41:15 | bauzas | mixed case: we need to use the same RC | |
| 12:41:23 | bauzas | non-mixed case : lgtm for another RC | |
| 12:41:39 | sean-k-mooney | well its not mixed in that we alwasy iknow if its form nova or cyborg | |
| 12:41:55 | sean-k-mooney | they will have different vnic types | |
| 12:42:04 | sean-k-mooney | in this case acclerator_direct vs direct | |
| 12:42:53 | gibi | does devices allocated for accelerator_direct tracked by nova pci tracker? I think it is not it is tracked by cyborg only | |
| 12:43:06 | sean-k-mooney | its only tracked by cyborg | |
| 12:43:09 | sean-k-mooney | like the vgpus | |
| 12:43:40 | sean-k-mooney | you could whitelist and track it in the pci tracker if it was stateless | |
| 12:44:04 | sean-k-mooney | cyborg only adds the ablity to flash an image on to it if need or do other stateful things | |
| 12:45:20 | sean-k-mooney | in the case of intels current propsal they are only supportin staticly pre programed devices but plan to make it dynmaic later | |
| 12:46:04 | sean-k-mooney | the current hardware does not manage the capailtie at the VF level, its card wide hence static intially until new hardware is release that is more granular | |
| 12:46:27 | swp20 | sean-k-mooney: so what's the main reason of the exception? | |
| 12:49:15 | gibi | sean-k-mooney: is it actually the first time that nova needs to handle this situation that both nova and another service tracks the same type of resource? | |
| 12:49:43 | gibi | in case of accelerator_direct we don't have the placement issue yet, as no PCI devices is modelled in placement yet | |
| 12:49:57 | gibi | so vgpu seems to be a first one when we actually do this | |
| 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 | |