Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-06-23
12:25:35 sean-k-mooney "When the Query.with_lockmode() method were deprecated in favor of Query.with_for_update()..."
12:26:45 sean-k-mooney looks like https://docs.sqlalchemy.org/en/14/orm/query.html#sqlalchemy.orm.Query.with_for_update is the replacemnt
12:27:04 sean-k-mooney swp20: https://docs.sqlalchemy.org/en/14/orm/query.html#sqlalchemy.orm.Query.with_for_update is the replacment for Query.with_lockmode()
12:27:26 swp20 sean-k-mooney: ok, i'll try to update. thanks a lot.
12:29:31 sean-k-mooney swp20: it looks like it was deprecated in 1.1 or 1.2 they just finally got around to droping it in 1.4
12:32:33 swp20 sean-k-mooney: thanks. the version in cyborg requirement.txt now is SQLAlchemy>=0.9.0,!=1.1.5,!=1.1.6,!=1.1.7,!=1.1.8 # MIT, i have update, hope this will success.
12:35:04 sean-k-mooney well you should not be capping the version locally in cyborg
12:35:39 sean-k-mooney that shoudl be managed via the upper constraitns file in the requirement repos
12:36:00 sean-k-mooney sicne all project are ment to be co installable the upper requrieemtn i manged cerntrally
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

Earlier   Later