| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-02-21 | |||
| 14:45:50 | gibi | I think in time we can learn to use it well | |
| 14:45:54 | sean-k-mooney | right but i dont think you should have to do that | |
| 14:46:10 | sean-k-mooney | i am hoping we will get the option to disable it personlly | |
| 14:46:48 | sean-k-mooney | its the frist time that gerrit has made a change that has made me consider if we shoudl continue to use gerrit longterm | |
| 14:47:14 | sean-k-mooney | to me the fact that comments were pined to reveriosn was one of the big benifits for using gerrit | |
| 14:47:17 | sean-k-mooney | this regresses that | |
| 14:48:00 | sean-k-mooney | i can see the beniftis too but to me in its current form the beiftis do not outway the downside | |
| 14:48:21 | gibi | hm, maybe a toggle in the UX to show / hide the old PS comments can be a compromise | |
| 14:48:32 | opendevreview | yuval proposed openstack/nova master: Lightbits LightOS driver https://review.opendev.org/c/openstack/nova/+/821606 | |
| 14:48:38 | sean-k-mooney | if it only forward ported the comment that refered to lines that were modified in the next revision i could proably live with that | |
| 14:49:35 | yuval_ | gibi sean-k-mooney thanks for the fast reply! | |
| 14:49:41 | sean-k-mooney | like its infurating that i have to load back up ps 8 to see why they refer too | |
| 14:50:53 | gibi | yuval_: will check the last version before end of my day | |
| 14:52:16 | yuval_ | thanks, I just updated as sean-k-mooney suggested the req file and lower constraints | |
| 14:52:23 | yuval_ | to see zuul pass | |
| 14:52:47 | yuval_ | I am now re-adding the lightbits ci to work on nova repo | |
| 14:53:00 | sean-k-mooney | yuval_: https://review.opendev.org/c/openstack/nova/+/821606/11/nova/virt/libvirt/volume/lightos.py#31 can you respond to this too | |
| 14:53:40 | yuval_ | yes, no problem | |
| 14:53:45 | dmitriis | sean-k-mooney, gibi: w.r.t. the above ping, I can chime in to help with reviews | |
| 14:54:14 | gibi | dmitriis: thanks | |
| 14:55:08 | gibi | dmitriis, sean-k-mooney: w.r.t. the sysfs pci_utils network.neutron coupling, I started looking into the refactor and I have to say that the whole resource tracker is infected with teh sysfs coupling via the pci device tracker | |
| 14:55:52 | sean-k-mooney | gibi: yes that is not surpriseing to be honest | |
| 14:56:08 | gibi | so this sean-k-mooney but then we are back to that the compute manager depends on sysfs | |
| 14:56:16 | sean-k-mooney | everything pci related is only supproted on linux today | |
| 14:56:47 | gibi | which is an acceptable limitation but the external depenency (sysfs) is not abstracted out | |
| 14:56:58 | gibi | and heavily tangled in | |
| 14:57:10 | sean-k-mooney | yes it is | |
| 14:57:31 | gibi | so I think today it would be extremely hard to add support to PCI for a non Linux host | |
| 14:57:45 | sean-k-mooney | it could certenly be factored more but i guess the expecation is you woudl add windows suport to the pci module if that ever came to be a thing | |
| 14:58:01 | gibi | hm | |
| 14:58:10 | gibi | yeah that would be an option too | |
| 14:58:14 | sean-k-mooney | gibi: well you would have to just implenet the supprot in the pci.utils module i | |
| 14:58:36 | gibi | I might have been overzealeus about this | |
| 14:58:50 | sean-k-mooney | its what we do in os-vif for what its worth https://github.com/openstack/os-vif/tree/master/os_vif/internal/ip | |
| 14:59:16 | sean-k-mooney | we have an ip module with a windows and linux impl | |
| 14:59:22 | gibi | yeah maybe that is a better direction | |
| 14:59:44 | gibi | maybe I just wish for a better defined pci.utils module | |
| 14:59:51 | gibi | where the interface is clear | |
| 15:00:08 | sean-k-mooney | ack | |
| 15:00:18 | sean-k-mooney | we kind of have grown it organicly over time | |
| 15:00:27 | gibi | yes, it is very organic :) | |
| 15:00:56 | gibi | like the init_host in the compute manager parses the whitelist config early but by that it already reading sysfs a lot :) | |
| 15:01:15 | sean-k-mooney | at some point i think we will want to unify mdev+pci+vdpa into a more uniform device tracker imple | |
| 15:01:16 | gibi | even if the compute manager itself does not use the whitelsit config at all | |
| 15:01:34 | gibi | sean-k-mooney: yeah that is also an interesting direction | |
| 15:01:43 | sean-k-mooney | gibi: parsing the whitelist does not hit sysfs | |
| 15:01:47 | gibi | it does | |
| 15:01:50 | sean-k-mooney | it should not | |
| 15:01:53 | gibi | yeah :d | |
| 15:01:58 | gibi | :D | |
| 15:02:01 | sean-k-mooney | parsing the whitelist does not look at the devices | |
| 15:02:13 | sean-k-mooney | it just reads the json and constucts the filter object | |
| 15:02:31 | sean-k-mooney | it should not make a single call to sysfs | |
| 15:02:50 | sean-k-mooney | https://github.com/openstack/nova/blob/0e0196d979cf1b8e63b9656358116a36f1f09ede/nova/pci/whitelist.py#L56-L83 | |
| 15:03:26 | gibi | https://github.com/openstack/nova/blob/0c31561792e0e13a9f8267e71fa484ab79957f04/nova/pci/devspec.py#L287 | |
| 15:03:34 | gibi | this is part of the Whitelist.__init__ codepath | |
| 15:03:59 | gibi | via PciDeviceSpec | |
| 15:04:32 | sean-k-mooney | it really should not me | |
| 15:04:37 | sean-k-mooney | https://github.com/openstack/nova/blob/0e0196d979cf1b8e63b9656358116a36f1f09ede/nova/pci/whitelist.py#L80 | |
| 15:04:44 | sean-k-mooney | is where you say the dep happens | |
| 15:05:12 | sean-k-mooney | that shoudl not be happening there | |
| 15:05:59 | sean-k-mooney | we shoudl only be asseting the valudes in the config are valid here | |
| 15:06:09 | gibi | yeah L80 eventually calls _init_dev_details in the PciDeviceSpec | |
| 15:06:18 | sean-k-mooney | i guess we just added the validation for remote managed here | |
| 15:06:29 | gibi | yes that is remote managed part now that calls out to sysfs | |
| 15:06:41 | sean-k-mooney | gibi: ok well the intent is we shoudl not hit sysfs in this code path | |
| 15:07:08 | sean-k-mooney | i had suggested moving the valdiation logic out of there and into the virt driver for remote-managed | |
| 15:07:14 | sean-k-mooney | perhaps we shoudl do that | |
| 15:08:17 | sean-k-mooney | everthing here https://github.com/openstack/nova/blob/0c31561792e0e13a9f8267e71fa484ab79957f04/nova/pci/devspec.py#L315-L351 shoudl really be in teh virt driver | |
| 15:08:54 | gibi | I think there is two places now that potentiall hit the remote managed validation path. 1) the init_host in the compute manager to early exit the compute service 2) the pci device tracker that cannot do anything with an invalid config as it is called from a periodic | |
| 15:09:25 | gibi | so we potentially need a 3rd place that is in the virt driver and part of the init sequence | |
| 15:09:33 | sean-k-mooney | init_host calls the driver | |
| 15:09:42 | sean-k-mooney | that si where this validation shoudl be done | |
| 15:10:27 | sean-k-mooney | in here https://github.com/openstack/nova/blob/0e0196d979cf1b8e63b9656358116a36f1f09ede/nova/virt/libvirt/driver.py#L707 | |
| 15:11:09 | gibi | yeah the confusion is that the validation is part of the whitelist config parsing and that config is compute level not libvirt level :/ | |
| 15:11:31 | sean-k-mooney | gibi: its not | |
| 15:11:33 | gibi | so it make sense to validate whitelist at the config level | |
| 15:11:39 | gibi | * compute level | |
| 15:11:39 | sean-k-mooney | well it is | |
| 15:11:56 | sean-k-mooney | validatign the whitelist is just ment to validate teh syntax | |
| 15:12:20 | sean-k-mooney | with some minor validation of the value in that product ids shoudl be in a certin range of allowed values | |
| 15:12:48 | sean-k-mooney | then avlidation of the semantics is ment to bve done in teh virt driver | |
| 15:14:05 | sean-k-mooney | i raised this in the reivew but i guess i did not see that code path. i did not think that was going to call those fucntion so that is a regression | |
| 15:15:39 | dmitriis | gibi: there's also the code path which uses interface names that calls out to sysfs | |
| 15:16:02 | sean-k-mooney | yes that is the qos code | |
| 15:16:11 | gibi | dmitriis: yes, there is a bunch of other coupling point. It is not just your patches introduced that | |
| 15:16:20 | gibi | sean-k-mooney: the qos code is going through the virt driver | |
| 15:16:22 | gibi | pci_info | |
| 15:16:40 | gibi | but there are other codes that goes to sysfs without the driver | |
| 15:16:40 | sean-k-mooney | gibi: yes | |
| 15:19:10 | sean-k-mooney | gibi: hum https://github.com/openstack/nova/blob/0e0196d979cf1b8e63b9656358116a36f1f09ede/nova/virt/hyperv/hostops.py#L194-L217 so hyperv apparently does support pci passhtough | |
| 15:19:38 | sean-k-mooney | but maybe not sriov | |
| 15:19:45 | sean-k-mooney | at least not with qos | |
| 15:19:54 | sean-k-mooney | well neutron sriov ports i mean | |
| 15:20:22 | sean-k-mooney | but we cant depend on sysfs in the whitelist parseing of it woudl break hyperv potentially | |
| 15:20:34 | sean-k-mooney | right now its guarded by the remote managed tag | |
| 15:20:47 | sean-k-mooney | so it wont actully break anything unless you set that in the whitelist | |
| 15:21:06 | sean-k-mooney | but this is much more fragile then i would like | |
| 15:21:50 | gibi | hyperv does not use the pci device tracker I assume | |
| 15:21:58 | sean-k-mooney | i think it does | |