Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-06-18
08:55:30 melwitt thanks o/
08:55:36 gibi o/
09:15:30 stephenfin gibi: I've addressed your comments on https://review.opendev.org/c/openstack/nova/+/786292/ if you have time today
09:48:19 opendevreview Lee Yarwood proposed openstack/nova stable/wallaby: Move 'check-cherry-picks' test to gate, n-v check https://review.opendev.org/c/openstack/nova/+/797039
09:49:54 opendevreview Lee Yarwood proposed openstack/nova stable/victoria: Move 'check-cherry-picks' test to gate, n-v check https://review.opendev.org/c/openstack/nova/+/797040
10:24:23 stephenfin Is it just me, or does building lower-constraints locally take, like, 5-10 minutes to run?
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: tests: Allow bindep and test-setup.sh to run on EL distros https://review.opendev.org/c/openstack/nova/+/796428
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: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

Earlier   Later