| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-02-15 | |||
| 14:11:05 | sean-k-mooney | even if they are not a vf and may not have a pci adress | |
| 14:11:21 | sean-k-mooney | at which point we might want to rename the module to be host_dev tracker or something | |
| 14:11:42 | sean-k-mooney | i kind of want it to eventualy track mdevs too | |
| 14:12:01 | sean-k-mooney | so it woudl be nice if we could unify it all in a common module | |
| 14:12:10 | sean-k-mooney | but that is not currently a priority for me | |
| 14:12:44 | sean-k-mooney | we alternitivly can use the generic resouces table to track these liek we do for persictent memroy namespaces | |
| 14:12:50 | sean-k-mooney | it was created to be generic | |
| 14:13:02 | sean-k-mooney | it might be a better fit for subfunciton and mdevs | |
| 14:13:19 | dmitriis | sean-k-mooney: on module renaming: yes, kind of going along the way VFIO is going (it has a common part and bus-specific parts) | |
| 14:13:28 | sean-k-mooney | but i have not really spent time looking, at least not in the last 2 years | |
| 14:15:26 | dmitriis | sean-k-mooney: one other direction which we haven't covered is ways for an operator to choose which device will be selected. E.g. in case of multiple DPUs per host or in the cloud we might want to supply product id-like info. | |
| 14:15:36 | dmitriis | currently InstancePCIRequest gets a generated spec | |
| 14:16:07 | sean-k-mooney | no | |
| 14:16:11 | sean-k-mooney | we do not | |
| 14:16:37 | sean-k-mooney | the operator gets to select which device are allowed | |
| 14:16:57 | sean-k-mooney | and can also associate them with a neutron phsyical network | |
| 14:17:18 | sean-k-mooney | but we explcitly do not want them to be able to select device via the pci aliase or the request by other means | |
| 14:17:41 | sean-k-mooney | what we could support is traits requests | |
| 14:17:58 | sean-k-mooney | or perhaps resouce classes | |
| 14:18:20 | sean-k-mooney | i have covered both of those in my pci in placment spec | |
| 14:18:44 | sean-k-mooney | https://review.opendev.org/c/openstack/nova-specs/+/791047 | |
| 14:18:51 | dmitriis | yeah, agreed. I didn't mean we want to specify bus-specific info in a request - just that there's no way to alter device selection | |
| 14:19:22 | dmitriis | ^ yes, that. I need to look at the spec again | |
| 14:19:24 | sean-k-mooney | it depend on what you mean by bus specific but in generally i dont think we shoudl | |
| 14:19:32 | sean-k-mooney | we can do it indrectly | |
| 14:19:38 | sean-k-mooney | vai resouce classes or traits | |
| 14:20:03 | sean-k-mooney | vendor id and product id are some what generic and somewhat specific | |
| 14:20:15 | sean-k-mooney | in that other buss tend to have a similar concept | |
| 14:20:29 | sean-k-mooney | like usb has a similar mapping | |
| 14:22:12 | dmitriis | sean-k-mooney: yeah, an indirect approach as with classes or traits would do it I think. | |
| 14:27:10 | sean-k-mooney | i was propsoing using CUSTOM_<Vendor_id>_<product_id> as the resouce class unless you set one in the pci whitelist | |
| 14:27:34 | sean-k-mooney | and extending the pci_alias to supprot a resouce class too | |
| 14:28:28 | sean-k-mooney | the neutron port could potentally specify it but in generally it woudl be nicer if it specified thigns like Support ipse via a HW_NET_IPSEC trait request instead | |
| 14:29:18 | sean-k-mooney | you would need a new neutron extenion however to tie that all together | |
| 14:39:07 | dmitriis | sean-k-mooney: yes, it would be preferable to use a Neutron extension the way I see it | |
| 14:40:20 | sean-k-mooney | there is a security consern with allow arbitry Resouce classes | |
| 14:40:36 | sean-k-mooney | but traits or vendor id and product id may be allowable | |
| 14:40:55 | sean-k-mooney | we perhasp could allow a RC but not allow you to specify the quantity | |
| 14:41:14 | sean-k-mooney | that is proably safe | |
| 14:53:31 | ralonsoh | sean-k-mooney, is it possible to run nova API without wsgi? | |
| 14:54:06 | sean-k-mooney | yes | |
| 14:54:11 | sean-k-mooney | well | |
| 14:54:20 | sean-k-mooney | without an external wsgi server yes | |
| 14:54:32 | sean-k-mooney | it still use wsgi but the python webserver | |
| 14:54:36 | sean-k-mooney | if you just run nova-api | |
| 14:54:38 | ralonsoh | to be able to run it in debug mode, with pycahrm | |
| 14:55:03 | sean-k-mooney | oh well that is harder you can try but eventlet tends to break things | |
| 14:55:23 | sean-k-mooney | in pycharm you can just have it launch the nova-api console script | |
| 14:55:28 | ralonsoh | sean-k-mooney, at least to know when the port receives the allocation information | |
| 14:55:43 | ralonsoh | ok, that could be an idea | |
| 14:56:01 | sean-k-mooney | you have to enabel the gevent pdb option | |
| 14:56:12 | sean-k-mooney | im not sure if its still considerd experimental or not | |
| 14:56:20 | sean-k-mooney | but it was off by default before in pycharm | |
| 14:56:39 | ralonsoh | it works fine | |
| 14:56:40 | sean-k-mooney | the gevent supprot help with debuging with eventlets | |
| 14:56:58 | sean-k-mooney | ya you could actuly disable eventlets in the nova-api | |
| 14:57:06 | sean-k-mooney | with an env argument | |
| 14:57:25 | sean-k-mooney | we only use it for one thing which is multi cell scater gater | |
| 14:57:58 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/monkey_patch.py#L98 | |
| 14:58:08 | sean-k-mooney | OS_NOVA_DISABLE_EVENTLET_PATCHING | |
| 14:58:13 | ralonsoh | yes, but the wsgi part? | |
| 14:58:29 | sean-k-mooney | the api is a wsgi applicaiton | |
| 14:58:50 | sean-k-mooney | you cant run it with out wsgi but you do not need mod_wsgi or uwsgi | |
| 15:00:52 | ralonsoh | sean-k-mooney, when the allocation info is added to the port? | |
| 15:01:35 | sean-k-mooney | as in placment allcoations | |
| 15:01:44 | sean-k-mooney | i belive as part of port binding | |
| 15:02:03 | sean-k-mooney | ralonsoh: i doubt that will happen in the api | |
| 15:02:08 | sean-k-mooney | it may | |
| 15:02:40 | sean-k-mooney | but conductor, is more likely if not the comptue or schduler | |
| 15:02:50 | ralonsoh | ok | |
| 15:03:19 | sean-k-mooney | the allcoation will only be know after we select the host so its after the api ahs started the async boot in the conductor | |
| 15:03:49 | bauzas | reminder: nova meeting in 57 mins | |
| 15:03:58 | sean-k-mooney | ralonsoh: https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L1172-L1181 | |
| 15:04:24 | ralonsoh | sean-k-mooney, yes but I have no idea who calls this method | |
| 15:04:35 | ralonsoh | compute | |
| 15:04:39 | sean-k-mooney | likely the compute agent or conductor | |
| 15:05:17 | sean-k-mooney | https://opendev.org/openstack/nova/src/branch/master/nova/compute/manager.py#L1769 | |
| 15:07:16 | gibi | ralonsoh: during normal VM create, that is called from the nova-compute service in build_and_run_instance | |
| 15:07:27 | gibi | but it is async as sean-k-mooney linked | |
| 15:07:30 | sean-k-mooney | ralonsoh: so ya this all happens on the compute node from build_and_run_instance | |
| 15:07:39 | ralonsoh | gibi, is there something extra I need to add for handling the QoS in the port? | |
| 15:07:50 | ralonsoh | for placement testing, I'm implementing the OVN placement support | |
| 15:08:10 | ralonsoh | (I have created the RPs when the chassis is created) | |
| 15:08:10 | sean-k-mooney | no if the port has the resouce request we shoudl include it | |
| 15:08:21 | gibi | ralonsoh: hm I have to look but I think that code has no conditional on OVN backend | |
| 15:08:32 | ralonsoh | perfect! | |
| 15:08:42 | gibi | so as sean-k-mooney said, make sure the port has resource request | |
| 15:08:49 | ralonsoh | yeah | |
| 15:08:53 | gibi | then nova should do the scheduling and allocation accordingly | |
| 15:09:02 | gibi | and then adds the RP uuid to the port during binding | |
| 15:09:40 | sean-k-mooney | ralonsoh: also check in the db. as you know neutron has a habbit fo resusing the request to generate teh respocne so if the extions is disabled in the neutron server it can say its there but not persist it into the db | |
| 15:09:54 | sean-k-mooney | which is what happened to me with port numa requests | |
| 15:10:10 | ralonsoh | sean-k-mooney, I'm retrieving this info from the chassis, not the RP | |
| 15:10:14 | sean-k-mooney | osc clearly showed it in the port create respocne but a show afterword did not have it | |
| 15:10:14 | ralonsoh | not the placement | |
| 15:10:34 | sean-k-mooney | i did not mention the RP | |
| 15:11:08 | sean-k-mooney | but i assume you mean you are retriving the bandwith inventories config options form the chassis | |
| 15:11:18 | ralonsoh | yes | |
| 15:11:31 | sean-k-mooney | to create the RP inventories in placment yes | |
| 15:12:04 | sean-k-mooney | the other half of it si actully requesting allcoations form that via the resouce_requests object in the port | |