| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-18 | |||
| 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 | |
| 12:58:11 | gibi | sean-k-mooney: I have no hard opinion about naming, if the doc is clear about that different classes results in different resource pools then I'm fine with the naming | |
| 12:58:23 | bauzas | sean-k-mooney: so I was expecting to look at the options to know the custom RCS | |
| 12:58:28 | sean-k-mooney | im not currently planning to support resource: syntax for pci passthough | |
| 12:59:06 | bauzas | sean-k-mooney: sorry, wrong method, this would be done in https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7763 | |
| 12:59:10 | sean-k-mooney | bauzas: ok | |
| 12:59:30 | sean-k-mooney | so for consitency should i include the same capablity in the pci spec? | |
| 12:59:55 | bauzas | sean-k-mooney: within this method, we would look at the known custom RCs besides the VGPU one | |
| 13:00:09 | sean-k-mooney | bauzas: i can determin the classes form pci_whitelist | |
| 13:00:29 | bauzas | sean-k-mooney: correct, I was expecting to look at the options | |
| 13:01:27 | gibi | sean-k-mooney: about PCI, we have an established way to request PCI, I would not extend on that as that can cause confusion. | |
| 13:01:49 | gibi | sure the PCI and the VGPU will be differnet from the flavor point of view | |
| 13:01:53 | gibi | but I think that is fine | |
| 13:02:02 | sean-k-mooney | i dont really like that personally | |
| 13:02:24 | sean-k-mooney | well its more i dont really like using resouce: as the only way to requst vgpus | |
| 13:02:35 | gibi | I see | |
| 13:02:37 | sean-k-mooney | but if we are supporting it for mdev i dont see why we would not support it for pci | |
| 13:02:53 | sean-k-mooney | i kind fo feel like we shoud go one way or the other | |
| 13:03:13 | gibi | I agree that having 'resource:' in the flavor is a shortcut, but it is an established form for VGPU already | |
| 13:03:14 | sean-k-mooney | the resouce class basiclaly will give use the same level of indrection the pci alais has today | |
| 13:03:28 | sean-k-mooney | but without the need to configure pci aliase in the first place | |