Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-06-23
12:10:28 sean-k-mooney i do think there will be other cases but in genral yes
12:10:44 bauzas if we mix, we could use the conductor to know whether we would ask cyborg or not
12:10:44 sean-k-mooney each RC tends to be specific ot a service
12:10:56 bauzas if we don't mix, we don't really need to have the same RC
12:10:57 sean-k-mooney cinder is the other example
12:11:24 sean-k-mooney it should be modeling its capastiy as disk_gb
12:11:36 sean-k-mooney which we use for local disk
12:11:43 sean-k-mooney ack
12:12:52 sean-k-mooney bauzas: gibi it sound like both of ye want to use a new resouce class so if that is what is requird to move this forward so be it
12:13:55 swp20 sean-k-mooney: hi, our cyborg tempest failed with the exception: Reason: 'Query' object has no attribute 'with_lockmode' . please help us with the refer:https://fc9dac502ce26d84f9de-05fc50868e17ec6a804428f62cd7e454.ssl.cf1.rackcdn.com/797427/4/check/cyborg-tempest/bd72fc3/job-output.txt
12:16:02 sean-k-mooney that might be form here https://github.com/openstack/cyborg/blob/ba6a35c67ee2e25cccc693d59cae2d2182aefa58/cyborg/db/sqlalchemy/api.py#L257
12:17:16 sean-k-mooney swp20: i suspect that it has change in the new version fo sqlacamy
12:18:14 sean-k-mooney i think the excption is comming form here https://github.com/openstack/cyborg/blob/bb35be1b86953c6df5fd9a300221cd45e359e8ec/cyborg/conductor/manager.py#L150-L158 or here https://github.com/openstack/cyborg/blob/bb35be1b86953c6df5fd9a300221cd45e359e8ec/cyborg/conductor/manager.py#L170-L175
12:18:26 swp20 it is because the placement changed the version of sqlalermy?
12:19:14 swp20 yeah, there are with_lockmode in cyborg project.
12:19:38 sean-k-mooney no not placment
12:19:42 sean-k-mooney Collecting SQLAlchemy===1.4.18
12:20:02 sean-k-mooney there was a new release of sql alchemy not so log ago
12:20:15 sean-k-mooney and all the pojects need to adapt too it
12:21:18 sean-k-mooney we updated to 1.4 2 months ago https://github.com/openstack/requirements/commit/dc86260b283dedc3076d7873f5f031f45e3e3671
12:21:33 sean-k-mooney it looks like that did not check for compatiablity in cyborg
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

Earlier   Later