| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-18 | |||
| 07:01:03 | opendevreview | Yongli He proposed openstack/nova master: smartnic support - new vnic type https://review.opendev.org/c/openstack/nova/+/771363 | |
| 07:01:06 | opendevreview | Yongli He proposed openstack/nova master: smartnic support https://review.opendev.org/c/openstack/nova/+/758944 | |
| 07:01:09 | opendevreview | Yongli He proposed openstack/nova master: smartnic support - reject server move and suspend https://review.opendev.org/c/openstack/nova/+/779913 | |
| 07:01:11 | opendevreview | Yongli He proposed openstack/nova master: smartnic support - functional tests https://review.opendev.org/c/openstack/nova/+/780147 | |
| 07:07:03 | yonglihe | alex_xu, addressed comments for 'smartnic support'. | |
| 08:49:24 | kevinz | Hi Nova, would be really appreciated if you can help to review this patch for live migrate on Arm64: https://review.opendev.org/c/openstack/nova/+/763928, the patch has been updated | |
| 08:50:54 | opendevreview | melanie witt proposed openstack/placement master: Microversion 1.37: API support for consumer types https://review.opendev.org/c/openstack/placement/+/679441 | |
| 08:50:59 | opendevreview | melanie witt proposed openstack/placement master: Switch ConsumerType to use an AttributeCache https://review.opendev.org/c/openstack/placement/+/679486 | |
| 08:52:26 | melwitt | gibi: just added a whackadoodle func test for the race scenario ^. I'm off tomorrow and next week so I just wanted to push this for now. still have to fix the rollback logic and address your other comments, will do that week after next | |
| 08:53:28 | melwitt | feel free to reapply your -1 to flag it | |
| 08:55:04 | gibi | melwitt: ack, thank. have a nice time off | |
| 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 | |