| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-02-21 | |||
| 09:53:20 | Uggla | But a share can be attached to several instances. So the model may need to be changed. Am I wrong ? | |
| 09:56:02 | bauzas | hmmmm | |
| 09:57:07 | Uggla | I would say we need a share_uuid field on the instance table to have a 1 to n relation ? | |
| 09:58:31 | Uggla | I could update the spec, but I would like to know if I have understand it well. | |
| 10:01:44 | bauzas | Uggla: oh, I just read again the spec | |
| 10:02:11 | bauzas | Uggla: nothing prevents you to have a share_mapping table with multiple share_uuid records having the same UUID | |
| 10:03:23 | Uggla | so we will have several records for the same share with a diff uuid. | |
| 10:03:36 | Uggla | so we will have several records for the same share with a diff instance_uuid. | |
| 10:03:38 | bauzas | I guess lyarwood wanted to tell we would do the same like for BlockDeviceMapping table | |
| 10:04:24 | bauzas | where we have a UC be the mapping UUID itself | |
| 10:04:31 | bauzas | not the volume UUID | |
| 10:04:44 | bauzas | Uggla: https://github.com/openstack/nova/blob/master/nova/db/main/models.py#L590 | |
| 10:05:38 | bauzas | either way, the PK on the bdmmapping table is a single 'id' key | |
| 10:05:38 | kashyap | Some more documentation on it - https://docs.openstack.org/nova/latest/user/block-device-mapping.html | |
| 10:06:00 | bauzas | thanks kashyap | |
| 10:08:22 | gibi | gmann: thanks I've started reading the new PSs this morning | |
| 10:12:19 | Uggla | Ok thanks, so in that case, maybe the share_mapping table requires an index on instance_uuid ? | |
| 10:13:24 | bauzas | Uggla: this depends whether you want to query from this field | |
| 10:14:00 | bauzas | Uggla: but since you'll tag a FK on instances.uuid, it will automatically generate an index | |
| 10:14:16 | bauzas | :) | |
| 10:14:29 | Uggla | ok | |
| 10:20:17 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Sort PCI devices by their address https://review.opendev.org/c/openstack/nova/+/830136 | |
| 10:24:33 | Uggla | Another question, looking at block device attachment, the api speaks directly to the compute api. Are there some specific rules that defines to speak through the conductor, or directly to the compute. Do we speak to the compute directly when we don't need to interact with the db at the first stage ? | |
| 10:24:41 | lyarwood | \o hey so yeah I thought I included a unique UUID per mapping between the instance and share? | |
| 10:26:45 | lyarwood | Uggla: the compute API isn't running on the compute, that's up in nova-api, the manager is the part running on the compute | |
| 10:27:58 | bauzas | lyarwood: I explained it to Uggla | |
| 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 | |