Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-02-21
10:28:13 bauzas https://specs.openstack.org/openstack/nova-specs/specs/yoga/approved/libvirt-virtiofs-attach-manila-shares.html#data-model-impact
10:28:21 bauzas Uggla: ^
10:28:23 lyarwood cool thanks and sorry I don't have this IRC client open anymore, only just saw the email :)
10:28:38 Uggla lyarwood, agreed my question is more the path api --> compute vs api --> cond --> compute ?
10:29:06 lyarwood Uggla: we only use the latter for long running tasks iirc like rebuilds, resizes etc
10:29:36 lyarwood Uggla: device attachments that are simple async operations tend to go directly between the api and compute
10:33:08 bauzas ++
10:33:47 bauzas also if we already know the compute
10:33:57 Uggla lyarwood, so the manila one drops down to the simple async op case, correct ?
10:34:37 lyarwood Yeah
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

Earlier   Later