| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-02-21 | |||
| 10:34:51 | lyarwood | and tbh it should be a noop at the moment as the instance is shutoff anyway | |
| 10:35:28 | lyarwood | starting the instance will recreate it within the libvirt driver and the logic to attach the mount needs to live there initially | |
| 10:35:40 | lyarwood | until we support hot plug | |
| 10:36:58 | Uggla | lyarwood, ok thx. | |
| 10:37:58 | Uggla | thank you for the answers, I think I can continue. | |
| 11:00:59 | opendevreview | yuval proposed openstack/nova master: Lightbits LightOS driver https://review.opendev.org/c/openstack/nova/+/821606 | |
| 11:03:21 | opendevreview | yuval proposed openstack/nova master: Lightbits LightOS driver https://review.opendev.org/c/openstack/nova/+/821606 | |
| 11:13:46 | sean-k-mooney | gibi: am well the pci module also is virt dirver indepenent and we explictily call sysfs in many cases to avoid depening on the virt driver | |
| 11:13:59 | sean-k-mooney | gibi: so that is already an established patteren | |
| 11:14:02 | gibi | :/ | |
| 11:14:14 | gibi | so basically nova-compute cannot run on windows with hyperv | |
| 11:14:19 | gibi | or it can but never handle PCI devices | |
| 11:14:34 | sean-k-mooney | gibi: they dont support pci device management | |
| 11:14:51 | gibi | yeah I figure that they cannot right now | |
| 11:14:55 | sean-k-mooney | so ya on windows they would have ti impelent all the fucntions in a windows compatiable way | |
| 11:15:16 | gibi | interestingly whent he pf_interface_name was added for QoS that was added via the virt driver interface | |
| 11:15:21 | sean-k-mooney | in os-vif we added an indriection layer in teh few places we needed it | |
| 11:15:44 | sean-k-mooney | gibi: yes which i changed since that was unreliable | |
| 11:15:58 | sean-k-mooney | due to libvirt design choices | |
| 11:16:16 | sean-k-mooney | mainly the way the cache and how that interacts with udev | |
| 11:17:31 | sean-k-mooney | gibi so right now the neutron use of sysfs is still confied to the sriov path | |
| 11:17:52 | sean-k-mooney | so i dont think this usage breaks windows support since that was already not supported | |
| 11:18:06 | sean-k-mooney | gibi: are there other usages that you found that would be common | |
| 11:18:16 | gibi | sorry I meant parent_ifname | |
| 11:18:26 | gibi | that is still done via the virt driver interface https://github.com/openstack/nova/blob/master/nova/virt/libvirt/host.py#L1321 | |
| 11:18:53 | sean-k-mooney | ah there | |
| 11:19:14 | gibi | sean-k-mooney: the new smartnic feature introduced a set of new dependencies between nova's neturon code (called from the compute manager) and sysfs | |
| 11:19:22 | sean-k-mooney | well its calling into the pci module to do it | |
| 11:19:39 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/host.py#L1322 | |
| 11:19:51 | sean-k-mooney | so that is not actully calling libvirt anymore | |
| 11:19:53 | gibi | yes but the call coming from the libvirt driver | |
| 11:20:05 | gibi | so the nova-compute does not depend on the sysfs in that case | |
| 11:20:10 | gibi | as the virtdirver hides it | |
| 11:20:37 | sean-k-mooney | yes this is genergating the virt independent view of the pci devices that is pass to the pci tracker | |
| 11:20:49 | sean-k-mooney | yes | |
| 11:21:33 | sean-k-mooney | gibi: so at one point i think i proposed storing the mac and vf number in addtion to the serial in the pci dev extra info | |
| 11:21:46 | sean-k-mooney | we could do that and remove the need to do this lookup entirly | |
| 11:21:55 | sean-k-mooney | in the neutorn module | |
| 11:22:50 | gibi | yeah my question is do we want two interfaces from compute manager towards the hypervisor host | |
| 11:23:10 | gibi | as today we have the virt interface and the pci_utils "interface" | |
| 11:23:40 | sean-k-mooney | thats fair i know os-brick also looks at the host filesystem | |
| 11:23:47 | sean-k-mooney | i guess that is hidden? | |
| 11:24:00 | gibi | do we call os-brick outside of the virt driver? | |
| 11:24:03 | sean-k-mooney | is os-brick only used via the virt dirver i assume so | |
| 11:24:19 | sean-k-mooney | ya i dont think we call it in the generic code | |
| 11:24:27 | sean-k-mooney | i was just trying to think what other indrections we have | |
| 11:24:48 | sean-k-mooney | i generally did not consider the nuetorn module to be part fo the compute manager | |
| 11:24:53 | sean-k-mooney | but it is call by it | |
| 11:25:03 | sean-k-mooney | i was thinking of it like the pci module | |
| 11:25:04 | gibi | I grepped now, os_brick only imported from under nova.virt (and in nova-manage)_ | |
| 11:25:10 | sean-k-mooney | ack | |
| 11:25:43 | sean-k-mooney | gibi: so i think we could file this as a bug and adress it without much extra work | |
| 11:25:54 | gibi | OK. I will file a bug. | |
| 11:26:36 | gibi | and probably I have too do the fixing as well as I need this to make the PF MAC address reporting to neutron | |
| 11:27:07 | gibi | as the current patch for that is also calling pci_utils from nova's neutron code instead of relying on the pci_info | |
| 11:27:10 | gibi | from the virt driver | |
| 11:27:52 | sean-k-mooney | ya it was an exsiting pattern but i agree the tight coupleing shoudl not exist between linux and the neutron module | |
| 11:28:57 | gibi | I think the pattern was established ~ 2015 when the first fix for the PF MAC address problem was added :D | |
| 11:29:06 | gibi | so everything is connected :D | |
| 11:29:17 | sean-k-mooney | there is one think to consider however | |
| 11:29:37 | sean-k-mooney | the pci tracker tracks pools of similar devices | |
| 11:30:11 | sean-k-mooney | so for PF mac and PF name that logicaly maps ok to pool fo the PF's VFs | |
| 11:30:42 | sean-k-mooney | the vf number will it can be tracked per device its not an atribute of the pool | |
| 11:31:10 | sean-k-mooney | so some of this info coudl be store in the db and some will have to be provided by the virt dirver per device | |
| 11:31:43 | sean-k-mooney | it can do that just by calling the existing fucntion when it creates the device object | |
| 11:32:09 | sean-k-mooney | but just pointing out that we might not be abel to hide this in the common pci module code | |
| 11:32:16 | sean-k-mooney | we might need to do this in the virt driver part | |
| 11:33:09 | sean-k-mooney | in any case it should be relitivly trivial to extend https://github.com/openstack/nova/blob/master/nova/objects/pci_device.py#L121 | |
| 11:33:49 | gibi | sean-k-mooney: currently the parent_ifname is part of the extra_info | |
| 11:33:51 | sean-k-mooney | in fact we could store the info in extra_info for backwards compatiablity without changing the object | |
| 11:33:56 | sean-k-mooney | ya | |
| 11:33:57 | gibi | yeah | |
| 11:34:14 | gibi | lets try that | |
| 11:34:24 | sean-k-mooney | so we can add the other field there and keep object compat and perhaps add properties for access | |
| 11:34:31 | gibi | yepp | |
| 11:34:50 | gibi | and that way I can still use that in my PF MAC address bugfix and keep it backportable | |
| 11:34:59 | sean-k-mooney | yes | |
| 11:35:37 | gibi | cool, thanks for the brainstroming | |
| 11:35:54 | gibi | :D | |
| 11:36:15 | gibi | yeah I feel the mental pain due to that json blobs in the db | |
| 11:36:26 | gibi | but the bugfix backporting pain is bigger | |
| 11:36:31 | gibi | so that won | |
| 11:40:22 | sean-k-mooney | honestly the only thing i woudl replace it with is a key value mapping table | |
| 11:40:26 | sean-k-mooney | like instance extra | |
| 11:40:38 | sean-k-mooney | * instance_system_metadata | |
| 11:40:58 | gibi | if the OVO model is just a Dict then changing the SQL model does not help architecturally | |
| 11:41:18 | sean-k-mooney | but that would not buy use much since we dont really query on the sub fileds | |
| 11:41:25 | sean-k-mooney | ya it doesnt really | |
| 11:42:53 | sean-k-mooney | if you work on this ping me and ill happily review i dont know if dmitriis woudl have time to work on it as a followup/techdebt cleanup | |
| 11:43:32 | gibi | sean-k-mooney: thanks. I will work on it as I need it for the PF MAC bugfix anyhow | |
| 11:44:35 | sean-k-mooney | :) ping me if you want me to review that too. speaking of which i should go look at the rest of your placement series | |
| 11:45:03 | sean-k-mooney | gibi: we defintly want to backport the PF fix if it ends up being posible by the way | |
| 11:45:25 | gibi | sean-k-mooney: I think it will be possible | |
| 11:45:40 | sean-k-mooney | i kind of feel like the backporatble fix and final fix would be different however | |
| 11:45:49 | gibi | sean-k-mooney: yeah, if you are done with the placement series then I will switch to that to fix the small thing in a followup | |
| 11:46:25 | gibi | sean-k-mooney: let's see about the backportability of the PF MAC | |
| 11:46:26 | sean-k-mooney | as in final fix would invovle multipel port bdingin but backporable would just unbind the port for the vm update the mac and reattach it or something like that | |
| 11:46:59 | gibi | sean-k-mooney: nope, the plan is to add the PF MAC to the binding:profile and let neutron do the overwrite of port.mac_addres based on that | |
| 11:47:10 | sean-k-mooney | oh right yes | |
| 11:47:20 | sean-k-mooney | you said that last week | |