| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-26 | |||
| 18:43:50 | sean-k-mooney | right before spawn i think that woudl fix it | |
| 18:44:41 | sean-k-mooney | you would need to change | |
| 18:44:42 | sean-k-mooney | with self.rt.instance_claim(context, instance, node, allocations, | |
| 18:44:44 | sean-k-mooney | limits): | |
| 18:44:53 | sean-k-mooney | to with self.rt.instance_claim(context, instance, node, allocations, | |
| 18:44:55 | sean-k-mooney | limits) | |
| 18:44:57 | sean-k-mooney | as claim | |
| 18:45:16 | sean-k-mooney | and then you could use the claim to get the pci diceis i think | |
| 18:49:28 | sean-k-mooney | artom: the update would look like this https://opendev.org/openstack/nova/src/branch/master/nova/compute/manager.py#L10634-L10657 | |
| 18:49:57 | sean-k-mooney | hum actullyno | |
| 18:51:10 | sean-k-mooney | well no this is how we actully do it for live miggration https://opendev.org/openstack/nova/src/branch/master/nova/compute/manager.py#L10597-L10632 | |
| 19:01:33 | artom | I guess we'd have to distinguish between unshelve from just SHELVED and also SHELVED_OFFLOADED | |
| 19:01:38 | sean-k-mooney | artom: in the normal spawn workflow after we take the instance calim we call _build_resources | |
| 19:01:54 | sean-k-mooney | which does call that yes | |
| 19:02:10 | sean-k-mooney | well it all alocate_netork | |
| 19:02:47 | sean-k-mooney | artom: https://github.com/openstack/nova/blob/68ad2c67d891935c66e8c0e5a368695c202a9f49/nova/compute/manager.py#L2349 | |
| 19:02:58 | sean-k-mooney | that is what allocate the networks on spawn normally | |
| 19:03:07 | artom | Yeah, I've been looking at that... | |
| 19:03:08 | sean-k-mooney | but we dont do that on unshelve | |
| 19:03:23 | artom | Which makes sense... but only if the instance was only shelved | |
| 19:03:40 | sean-k-mooney | well we woudl be calling it form unshelve | |
| 19:03:54 | sean-k-mooney | here https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L6579 | |
| 19:04:13 | sean-k-mooney | litrally after the instance_claim but just before spawn | |
| 19:06:49 | sean-k-mooney | this is where its update for other move ops right https://github.com/openstack/nova/blob/68ad2c67d891935c66e8c0e5a368695c202a9f49/nova/network/neutron.py#L3394-L3419 | |
| 19:07:04 | sean-k-mooney | but since thre is no migration that oviously does not work | |
| 19:09:04 | artom | Ah, we can't allocate_for_instance on unshelve because even OFFLOADED instances keep their ports | |
| 19:09:15 | artom | So I'd think all kinds of things would explode | |
| 19:09:35 | artom | We really do need just the _update, but we need to somehow pull the PCI info from the claim, and pass that to the neutron api later | |
| 19:09:37 | sean-k-mooney | maybe | |
| 19:09:38 | artom | *layer | |
| 19:09:42 | sean-k-mooney | its doing more then we want anyway | |
| 19:10:40 | sean-k-mooney | _update_ports_for_instance is closer | |
| 19:11:39 | sean-k-mooney | https://github.com/openstack/nova/blob/68ad2c67d891935c66e8c0e5a368695c202a9f49/nova/network/neutron.py#L1498-L1524 | |
| 19:12:01 | sean-k-mooney | this is what actully update the port with the bindingprofile | |
| 19:12:22 | sean-k-mooney | the issue is we dont have a way to map the neutorn por tto the pci_request_id | |
| 19:12:46 | sean-k-mooney | if we had that we woudl jsut get the dev doing | |
| 19:12:50 | sean-k-mooney | pci_devices = pci_manager.get_instance_pci_devs( | |
| 19:12:52 | sean-k-mooney | instance, pci_request_id) | |
| 19:13:23 | sean-k-mooney | then https://github.com/openstack/nova/blob/68ad2c67d891935c66e8c0e5a368695c202a9f49/nova/network/neutron.py#L1487-L1496 | |
| 19:13:29 | artom | sean-k-mooney, yeah, I'm hitting that exact issue | |
| 19:13:37 | artom | With the migration, we have the mapping from old to new | |
| 19:13:38 | sean-k-mooney | would get that for us | |
| 19:13:46 | sean-k-mooney | yep | |
| 19:13:59 | sean-k-mooney | so i looked at sotring the pci resuet id in the vif breilfy | |
| 19:14:11 | sean-k-mooney | but unfortunetly that is a object change | |
| 19:14:57 | sean-k-mooney | hum https://github.com/openstack/nova/blob/68ad2c67d891935c66e8c0e5a368695c202a9f49/nova/network/neutron.py#L2112 | |
| 19:14:57 | artom | I'm assuming pci_vendor_info and physical_network from the port binding isn't enough | |
| 19:15:02 | artom | Even assuming we have the latter | |
| 19:15:23 | sean-k-mooney | https://github.com/openstack/nova/blob/68ad2c67d891935c66e8c0e5a368695c202a9f49/nova/network/neutron.py#L2165 | |
| 19:15:48 | sean-k-mooney | the pci request id shoudl be the nueturno port uuid | |
| 19:15:52 | artom | Ohhh | |
| 19:16:29 | sean-k-mooney | so i thnk we can look it up like that? | |
| 19:18:13 | sean-k-mooney | so if we get teh port we could loop over therm calling https://github.com/openstack/nova/blob/68ad2c67d891935c66e8c0e5a368695c202a9f49/nova/network/neutron.py#L1498-L1524 | |
| 19:18:41 | sean-k-mooney | passing the port['id'] as pci_request_id | |
| 19:18:55 | sean-k-mooney | and then after that has updated them in memeory we woudl do a port update? | |
| 19:19:22 | sean-k-mooney | then i think we cloud call driver .spawn | |
| 19:20:39 | sean-k-mooney | artom: do you think that would work? | |
| 19:31:28 | sean-k-mooney | ... its not the neutron port uuid | |
| 19:31:52 | artom | sean-k-mooney, think so, yeah | |
| 19:31:58 | artom | Lemme try it | |
| 19:33:11 | sean-k-mooney | artom: the requester_id is the neutron port uuid | |
| 19:33:25 | sean-k-mooney | the pci_request_id is the request_id | |
| 19:33:40 | sean-k-mooney | unfortunetly the requester_id is not sotred in teh db | |
| 19:34:54 | sean-k-mooney | the requested_networks network object i think is the only thing that has the mapping | |
| 19:35:51 | sean-k-mooney | i think this is the same roadblock i hit the last time | |
| 19:39:40 | sean-k-mooney | ... | |
| 19:39:51 | sean-k-mooney | so the instance_extra tbale has it but not fully | |
| 19:39:54 | sean-k-mooney | [{"count": 1, "spec": [{"physical_network": "public"}], "alias_name": null, "is_new": false, "numa_policy": "preferred", "request_id": "03e6f4be-dc49-4825-a33d-337f2708be22", "requester_id": null} | |
| 19:40:17 | sean-k-mooney | the requester_id shoudl be the neutorn port uuid | |
| 19:40:51 | sean-k-mooney | if it was we coudl get the request id and then look up the claimed deivce in the pci device table and mapt them back to the ports | |
| 19:43:02 | sean-k-mooney | artom: i think im going to call it a day there. if we fixed that so the requester id was always set then we could use that | |
| 19:43:35 | sean-k-mooney | i think it curently not set becasue we dont save this back to the db and only pass it around | |
| 19:43:49 | sean-k-mooney | https://github.com/openstack/nova/blob/68ad2c67d891935c66e8c0e5a368695c202a9f49/nova/network/neutron.py#L2154-L2164 | |
| 19:44:26 | artom | sean-k-mooney, ack yeah, my brain is getting rusty as well | |
| 19:47:12 | sean-k-mooney | we might need to do this in two parts | |
| 19:47:37 | sean-k-mooney | one patch that fixes populating that value and tries to file it in for exsitng instnace | |
| 19:47:47 | sean-k-mooney | maybe using the pci_slot | |
| 19:48:03 | sean-k-mooney | to figure out thte mappign between port and exctra | |
| 19:48:29 | sean-k-mooney | and tehn a secdond to use it to update the port or something like that | |
| 19:48:45 | sean-k-mooney | anyway enjoy your weekend | |
| 19:49:14 | sean-k-mooney | what frustrating abtout this is every time i look at this we have almsot all the info we need | |
| 19:49:17 | sean-k-mooney | almost | |
| #openstack-nova - 2021-03-27 | |||
| 13:42:18 | openstackgerrit | Takashi Natsume proposed openstack/nova master: Update contributor guide for Xena https://review.opendev.org/c/openstack/nova/+/783534 | |
| 15:27:03 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Neutron fixture: don't clobber profile and vif_details if empty https://review.opendev.org/c/openstack/nova/+/783385 | |
| 15:27:04 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Test SRIOV port move operations with PCI conflicts https://review.opendev.org/c/openstack/nova/+/783084 | |
| #openstack-nova - 2021-03-29 | |||
| 07:59:11 | bauzas_ | good morning | |
| 07:59:24 | bauzas_ | gibi: a bit on and off as I need to restart my ZNC bouncer a couple of times | |
| 07:59:38 | gibi | bauzas_: good morning. ack | |
| 07:59:39 | bauzas_ | (changed my NAS who supports it) | |
| 08:14:10 | bauzas_ | hopefully, last ZNC bouncer recycle | |
| 08:19:56 | openstackgerrit | Merged openstack/osc-placement master: Update master for stable/wallaby https://review.opendev.org/c/openstack/osc-placement/+/781894 | |
| 10:28:14 | openstackgerrit | Merged openstack/nova stable/wallaby: [stable-only]Update .gitreview for stable/wallaby https://review.opendev.org/c/openstack/nova/+/783195 | |
| 10:28:27 | openstackgerrit | Merged openstack/nova stable/wallaby: [stable-only]Update TOX_CONSTRAINTS_FILE for stable/wallaby https://review.opendev.org/c/openstack/nova/+/783216 | |
| 10:55:55 | openstackgerrit | Xinran WANG proposed openstack/nova-specs master: Repropose smartnic support spec https://review.opendev.org/c/openstack/nova-specs/+/783632 | |
| 11:25:28 | stephenfin | kashyap: Can you revisit https://review.opendev.org/c/openstack/nova/+/781438/? | |
| 11:25:41 | stephenfin | I've added a follow-up addressing your comments here https://review.opendev.org/c/openstack/nova/+/782410/ | |
| 12:56:09 | kashyap | stephenfin: Queued (I see it's the CPU models doc) | |
| 13:38:08 | sean-k-mooney | stephenfin: did you see my comments on the sev one that is already merged https://review.opendev.org/c/openstack/nova/+/781437/2/doc/source/admin/sev.rst | |
| 14:09:04 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/victoria: Add regression test for bug #1908075 https://review.opendev.org/c/openstack/nova/+/783653 | |
| 14:09:05 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/victoria: api: Reject volume attach requests when an active bdm exists https://review.opendev.org/c/openstack/nova/+/783654 | |