| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-18 | |||
| 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 | |
| 12:54:56 | bauzas | sean-k-mooney: sure, shoot | |
| 12:55:10 | sean-k-mooney | how are you planning to determin that a RC is an request for an MDEV to be passed through | |
| 12:55:11 | bauzas | gibi: agreed | |
| 12:55:12 | gibi | s/to/too/ | |
| 12:55:22 | bauzas | gibi: we should document this | |
| 12:55:29 | gibi | bauzas: agreed | |
| 12:55:30 | sean-k-mooney | are you on the compute node going to look at all the RC in the config for mdevs and then just compare to that list | |
| 12:55:49 | bauzas | gibi: that's why I used the wording "class" and not "type" | |
| 12:56:22 | bauzas | gibi: in theory, that's for apples vs. bananas | |
| 12:56:28 | bauzas | gibi: and not about apple flavors | |
| 12:56:37 | sean-k-mooney | or should we havee a mdev_request:<RC>=<amount>,<RC>=<Amount>,... extra specs | |
| 12:56:54 | bauzas | sean-k-mooney: I was expecting to reuse this method, sec | |
| 12:57:29 | sean-k-mooney | gibi: bauzas would it be clear to use resouce_class instead of mdev_class in the cofnig | |
| 12:57:37 | bauzas | sean-k-mooneyhttps://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7377 | |
| 12:57:58 | bauzas | sean-k-mooney: meh, I'm not opiniated by the option name | |
| 12:58:01 | sean-k-mooney | bauzas: the reason im asking is for the pci in placement spec by the way | |