Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-06-18
10:24:31 stephenfin guess there's a lot of dependency resolution going on
10:26:19 opendevreview Lee Yarwood proposed openstack/nova stable/ussuri: Move 'check-cherry-picks' test to gate, n-v check https://review.opendev.org/c/openstack/nova/+/797050
10:27:18 opendevreview Lee Yarwood proposed openstack/nova stable/train: Move 'check-cherry-picks' test to gate, n-v check https://review.opendev.org/c/openstack/nova/+/797052
10:27:23 lyarwood can't say I've tried recently but I can give it a go now
10:28:39 stephenfin yeah, it's still ongoing here 10 minutes later
10:29:13 gibi stephenfin: it is slow to me too
10:30:51 stephenfin aaaand it failed because it's trying to run with the default python3 version, so 3.9.5 on my host :-(
10:31:09 opendevreview Stephen Finucane proposed openstack/nova stable/wallaby: libvirt: Delegate OVS plug to os-vif https://review.opendev.org/c/openstack/nova/+/790447
10:32:49 lyarwood stephenfin: lol it failed in like 30 seconds for me because of 3.9
10:33:15 lyarwood stephenfin: building greenlet right?
10:33:18 stephenfin yup
10:33:26 stephenfin I guess you had the packages locally already
10:34:19 lyarwood right so it isn't pip for you at least
10:34:33 lyarwood ah well I guess it does that before downloading
10:34:37 lyarwood so maybe it is
10:34:58 gibi yup greenlet for me too
10:35:13 gibi it take 5 minutes on my laptop to fail
10:36:21 lyarwood with 3.8 it takes ~30 seconds before tests start running
10:36:42 opendevreview Stephen Finucane proposed openstack/nova master: tox: Encode specific Python versions https://review.opendev.org/c/openstack/nova/+/797054
10:36:44 lyarwood with a fresh .tox folder but lots cached on the host
10:36:47 stephenfin lyarwood: gibi: ^
10:37:07 lyarwood stephenfin: I'm sure I suggested this in the past but gmann had reasons not to do it
10:37:13 stephenfin it'll be nice to be able to use the 'functional' env (vs. 'functional-py38') again
10:37:20 lyarwood aye
10:37:52 lyarwood https://governance.openstack.org/tc/reference/runtimes/xena.html tbh 3.9 isn't listed as a supported runtime anyway so we should really cap
10:37:56 stephenfin I don't see any disadvantage other than the busywork aspect I've noted
10:38:38 stephenfin we use 'py3' as a default env in oslo land but the oslo libs are far simpler with fewer dependencies likely to cause issues on other python versions
10:57:58 stephenfin lyarwood: Okay, got lower-constraints working and https://review.opendev.org/c/openstack/nova/+/790447 is now passing locally. Could you take a look today or early next week? I'd ping melwitt too but she's out now
10:58:22 stephenfin I purposefully pushed the changes up separately, so you should be able to diff PS1 and PS3 to see what I did, in case the commit message isn't clear
10:58:32 stephenfin *changes from the master version
11:32:37 lyarwood stephenfin: left some quick comments, I might be missing something tbh but I don't see tests for the check_can_live_migrate_destination changes?
11:34:50 opendevreview sean mooney proposed openstack/nova master: Test numa and vcpu topologies bug: #1910466 https://review.opendev.org/c/openstack/nova/+/769601
11:34:51 opendevreview sean mooney proposed openstack/nova master: Fix max cpu topologies with numa affinity https://review.opendev.org/c/openstack/nova/+/769614
11:35:45 opendevreview Lee Yarwood proposed openstack/nova master: zuul: Add nova-tox-functional-centos8-py36 job https://review.opendev.org/c/openstack/nova/+/796684
11:35:45 opendevreview Lee Yarwood proposed openstack/nova master: tests: Allow bindep and test-setup.sh to run on EL distros https://review.opendev.org/c/openstack/nova/+/796428
11:38:29 sean-k-mooney wow my console is jsut being spamed by sqlacmy warnings when i run the functional test
11:39:06 sean-k-mooney TypeDecoratro softDeleteInterger somethign something
11:41:55 sean-k-mooney /home/sean/repos/openstack/nova/nova/db/sqlalchemy/api.py:419: SAWarning: TypeDecorator SoftDeleteInteger() will not produce a cache key because the ``cache_ok`` flag is not set to True. Set this flag to True if this type object's state is safe to use in a cache key, or False to disable this warning.
11:41:57 sean-k-mooney return dict(min_versions)
11:41:59 sean-k-mooney /home/sean/repos/openstack/nova/nova/db/sqlalchemy/api.py:473: SAWarning: TypeDecorator SoftDeleteInteger() will not produce a cache key because the ``cache_ok`` flag is not set to True. Set this flag to True if this type object's state is safe to use in a cache key, or False to disable this warning.
11:42:01 sean-k-mooney result = model_query(context, models.Service, read_deleted="no").\
11:43:09 sean-k-mooney gibi: is that related to the sqlalchmey change we need to make for the latest version
11:55:16 opendevreview Merged openstack/nova master: Add --task-log option to nova-manage db archive_deleted_rows https://review.opendev.org/c/openstack/nova/+/780395
12:11:18 gibi sean-k-mooney: I think this a change in sqla 1.4 that we need to adapt to
12:12:09 gibi I had not time to look into which value should we set for cache_ok
12:12:23 sean-k-mooney ok i guess we just set them to cache_ok=false
12:13:27 gibi this soft delete thing is coming from oslo_db so I guess we should set the flag there
12:38:49 gibi bauzas: do you have a couple minutes to talk about the mdev spec
12:38:50 gibi ?
12:39:02 bauzas gibi: sure, shoot
12:39:05 gibi cool
12:39:16 gibi I think I missunderstood some port of the proposal
12:39:30 bauzas ah ?
12:40:01 gibi today we have the VGPU resource class in placement
12:40:17 gibi how do we use that if there are multiple vgpu types are enabled?
12:41:02 bauzas gibi: two possibilities
12:41:51 bauzas gibi: either you don't need to use types
12:42:10 bauzas and then even if you have multiple types, any of them will be used
12:42:14 bauzas or, you use traits
12:42:17 gibi I see
12:42:48 gibi so we always represent every vgpu type as VGPU inventory in placement, and if the deployer wants to differentiate between types then he needs to use traits
12:44:32 gibi do I understand it correctly?
12:45:25 gibi assume yes. :)
12:46:03 gibi so then we introduce generic mdev support
12:46:07 bauzas sorry, I was afk
12:46:16 bauzas yes, indeed
12:46:28 gibi and there we say each mdev type is a new CUSTOM RC
12:47:31 gibi so if I have enabled_vgpu_types = A, B, today then both represented az VGPU inventory, but when I translate that to the new enabled_mdev_types =A, B there will be two new CUSTOM RCs?
12:47:57 gibi so the logic changes
12:48:05 sean-k-mooney that is an interesting point
12:48:14 gibi what is a single resource pool today, will be two separate pool tomorrow
12:48:19 sean-k-mooney i guess when translating we would have to map both to vgpu
12:49:06 gibi sean-k-mooney: to be able to translate we need to know which mdev type represents a vgpu
12:49:14 gibi to put them into the same pool
12:49:21 bauzas sean-k-mooney: gibi: by default, this could not change
12:49:23 sean-k-mooney gibi: oh kno i ment have a config option
12:49:29 sean-k-mooney mdev_type -> RC
12:50:00 bauzas sean-k-mooney: gibi: but if the operator use a different mdev_class per type, yes
12:50:50 sean-k-mooney bauzas: well even in th vgpu case i think ti woudl be nice to use custom RCs instead of VGPU + trait
12:50:59 gibi hm
12:51:19 sean-k-mooney one thing i have been wonderign is do we want to have a different mechanium to request this
12:51:32 gibi so we can use the same mdev_class = vgpu to two different mdev type
12:51:38 sean-k-mooney e.g. an mdev: extra spec
12:51:39 bauzas sean-k-mooney: the config options I provided in https://review.opendev.org/c/openstack/nova-specs/+/792796/3/specs/xena/approved/generic-mdevs.rst could do this
12:52:14 sean-k-mooney kind of like the pci alais
12:52:26 sean-k-mooney bauzas: yes it can
12:52:45 bauzas gibi: do you have concerns with this ?
12:53:08 sean-k-mooney gibi: yes you would have mdev_class = vgpu in two different mdev type
12:53:11 bauzas for the moment, we indeed use traits for vgpu types https://docs.openstack.org/nova/latest/admin/virtual-gpu.html#optional-provide-custom-traits-for-multiple-gpu-types
12:53:21 gibi bauzas: actually I've just relaized that my using the same mdev_class in two different types the pooling can be defined precisely
12:53:35 lyarwood artom / sean-k-mooney ; https://review.opendev.org/c/openstack/nova-specs/+/794799 - would you mind taking another look at this btw?
12:53:38 gibi s/my/by/
12:53:52 bauzas gibi: if you use mdev_class='vgpu' which is the default, then you will have two inventories with the same RC
12:54:01 gibi bauzas: cool, that works for me
12:54:08 sean-k-mooney lyarwood: sure ill take a look tat this soon after ^
12:54:25 lyarwood ack thanks :)
12:54:28 sean-k-mooney bauzas: i have one question though
12:54:29 bauzas gibi: if you use other mdev_class value, you will still have two inventories but with different RCs
12:54:46 sean-k-mooney from the generic resouces:request in the flavor
12:54:53 gibi bauzas: and then what I really want is to tell the consumers of the generic mdev feature not to use to specific RC names for different types but uses custom traits instead as that is more flexibly when you request things

Earlier   Later