| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-08-24 | |||
| 10:10:24 | gibi | yes I assumed so, what I did not relaized that the fixture automatically split devices equally between numa0 and numa1 | |
| 10:10:31 | sean-k-mooney | but i guess it combines if they are the same | |
| 10:10:49 | sean-k-mooney | ah yes it does | |
| 10:11:06 | sean-k-mooney | you can just create the device manually but the fixture i generally nicer to use | |
| 10:11:14 | gibi | yep | |
| 10:13:36 | gibi | basic cold migrate and resize works with miniumal changes in the conductor so I think evac and unshelve will be easy too | |
| 10:13:53 | gibi | and live migration is not supported for flavor based PCI so that is super easy :D | |
| 10:14:31 | gibi | then I will look at resize revert, reschedule, and multi create in this order | |
| 10:15:14 | sean-k-mooney | lol yep live migration should be trivial :P | |
| 10:15:45 | sean-k-mooney | fortunetly you can also verify them on real hardware for a change too once its working in the func test env | |
| 10:15:58 | gibi | yes I will do a final round in the lab too | |
| 10:16:17 | sean-k-mooney | i still need to go extend the reservation fo those nodes | |
| 10:16:20 | sean-k-mooney | ill do that now | |
| 10:16:22 | gibi | thanks | |
| 10:16:52 | gibi | I use those nodes to run the func and unit tests in bluk too as it is a lot faster there :D | |
| 10:17:24 | gibi | I rsync up my local dev repo and run tox via ssh | |
| 10:17:31 | sean-k-mooney | yep thats why i often do dev on my home server | |
| 10:17:49 | opendevreview | ribaudr proposed openstack/nova master: Default Nova persistent objects without soft delete. https://review.opendev.org/c/openstack/nova/+/854355 | |
| 10:18:05 | sean-k-mooney | its avaiabel until 02-Nov-2022 but that seem longer then we need any prefered end date | |
| 10:18:15 | sean-k-mooney | we can return them early too | |
| 10:18:26 | sean-k-mooney | will i extend it to october 1st? | |
| 10:18:34 | sean-k-mooney | that gives us a month of grace period | |
| 10:19:01 | gibi | oct 1 is totally ok | |
| 10:20:49 | sean-k-mooney | ok done | |
| 10:20:58 | gibi | thanks | |
| 10:21:38 | gibi | OK, so pools are splitted on these keys https://github.com/openstack/nova/blob/master/nova/pci/stats.py#L66 and I need to actaully check parent_addr there as well | |
| 10:22:25 | gibi | if the parent_addr is None or not equal betweent two devs then we need to split | |
| 10:22:51 | sean-k-mooney | yep that makes sense | |
| 10:23:03 | sean-k-mooney | although hum | |
| 10:23:11 | sean-k-mooney | we shoudl be spliting on more then that | |
| 10:23:15 | sean-k-mooney | like phsynet | |
| 10:23:44 | gibi | yes for neutron based sriov we might need that too | |
| 10:24:02 | sean-k-mooney | can you add that while your adding the partent adress | |
| 10:24:32 | sean-k-mooney | im wondering about trusted too | |
| 10:24:49 | sean-k-mooney | i dont know if we need to split based on that | |
| 10:24:49 | gibi | wait | |
| 10:25:00 | gibi | I have to correct myself | |
| 10:25:18 | gibi | https://github.com/openstack/nova/blob/94065763d32287606895c07bd5882bab083a4e48/nova/pci/stats.py#L136-L138 | |
| 10:25:29 | gibi | we split on both those dev fields and the devspec tags | |
| 10:25:39 | gibi | to physnet is handled | |
| 10:26:02 | sean-k-mooney | ah ok as is trusted | |
| 10:26:32 | sean-k-mooney | so this will auto split on traits and resouce class | |
| 10:26:50 | gibi | hehe :) | |
| 10:26:50 | sean-k-mooney | technially we allow operator provided tags too but they were never uable for anything | |
| 10:26:53 | sean-k-mooney | we just ignore them | |
| 10:27:46 | sean-k-mooney | at one point there was talk of allowign the pci alias to match on extra tags | |
| 10:27:51 | gibi | I had to ignore traits and resource_class https://review.opendev.org/c/openstack/nova/+/853316/4/nova/pci/stats.py to keep the pool matching work | |
| 10:28:55 | sean-k-mooney | ah ok hehe | |
| 10:29:10 | gibi | it is mostly ther to keep _filter_pools_for_spec happy as the request contains the traits tag but the pool will not mapped to traits just to RPs | |
| 10:29:35 | sean-k-mooney | ya thats proably fine | |
| 10:31:25 | sean-k-mooney | will we have the tags in the pools | |
| 10:31:28 | sean-k-mooney | *traits | |
| 10:31:50 | sean-k-mooney | i assume the intent is just to relay on placment to do the trait/rc filtering | |
| 10:32:07 | sean-k-mooney | and then we use the rp id to corralate the pools with the allcoation candaate | |
| 10:32:12 | sean-k-mooney | so we dont need to check them in the filters | |
| 10:32:27 | sean-k-mooney | so we can just not put them in the pools | |
| 10:33:17 | gibi | we use the rp_uuid to correlate the request with the pool | |
| 10:33:23 | gibi | the rest is doen in placemnet | |
| 10:34:16 | sean-k-mooney | yep that is what i was expecting | |
| 10:34:36 | gibi | the pooling logic uses all the dev_spec tags automatically so I needed to explicity ignore traits and resource_class there | |
| 10:34:47 | gibi | to not to put them into the pool | |
| 10:34:50 | gibi | as we don't need them | |
| 10:35:04 | gibi | and it also won't match with the request in generic way | |
| 10:35:09 | sean-k-mooney | so your going to do two change right. 1 split the pools now also by parent adress and 2 split the alias requests into multipel instance_pci_request object if the alias request more then one of something | |
| 10:35:18 | gibi | yes | |
| 10:35:21 | gibi | the later is already up | |
| 10:35:28 | gibi | I doing the former now | |
| 10:35:55 | gibi | https://review.opendev.org/c/openstack/nova/+/852771/6/nova/objects/request_spec.py#540 | |
| 10:36:03 | gibi | this is the request splitting ^^ | |
| 10:37:22 | sean-k-mooney | cool ill try and review more of the seriese today | |
| 10:37:39 | gibi | thanks | |
| 10:37:51 | sean-k-mooney | i have some coments on the ones i reviewd but im +2 on all the ones i have reviewed so far | |
| 10:38:00 | gibi | I will go through your comment | |
| 10:38:24 | sean-k-mooney | i had a littele bit of consern with https://review.opendev.org/c/openstack/nova/+/846470 | |
| 10:38:34 | gibi | I just want to make the functionality complete first. If you see some dealbreaker in the series then use -1 so I will stop and go back to it | |
| 10:38:42 | sean-k-mooney | but i think the pci tracker will be sufficent to protect us | |
| 10:38:55 | sean-k-mooney | ack | |
| 10:39:22 | sean-k-mooney | so i just want to highligh a subtle behavior that you may or may not be aware of | |
| 10:39:40 | sean-k-mooney | if a pci device has a claim against it in the pci_devices table | |
| 10:39:53 | sean-k-mooney | and you remove it form the pci whitelist/dev spec | |
| 10:40:04 | sean-k-mooney | we do not remove it form teh pci tracker until the vm is delete or moved | |
| 10:40:19 | sean-k-mooney | that is to prevent you form currupting your db | |
| 10:40:31 | gibi | yes | |
| 10:40:35 | sean-k-mooney | by typoing the config | |
| 10:40:41 | sean-k-mooney | so we need to make sure we dont break that | |
| 10:40:45 | gibi | I follow that logic in the placement side as much as I can | |
| 10:40:52 | sean-k-mooney | ack | |
| 10:40:57 | sean-k-mooney | that is what i was wondering | |
| 10:41:10 | sean-k-mooney | i was hoping that we woudl not remove RPs if they had allcoations | |
| 10:41:13 | gibi | the commit message has an edge case described when nova will fail to start though https://review.opendev.org/c/openstack/nova/+/852397/5//COMMIT_MSG | |
| 10:41:54 | sean-k-mooney | this else branch https://review.opendev.org/c/openstack/nova/+/846470/15/nova/compute/pci_placement_translator.py#320 | |
| 10:42:02 | gibi | but other than that the PCI RP will be kept until the PCIDevice is in the nova DB | |
| 10:42:18 | sean-k-mooney | is for the case where its in the pci tracker with a claim agaisnt it but removed form the config right | |
| 10:42:54 | gibi | at that point in the series we have no allocations against PCI RPs. so we just ignore the device without spec | |
| 10:43:14 | sean-k-mooney | we ignore removign it | |
| 10:43:35 | sean-k-mooney | so the rp stays there whiel the device is not deleted in the pci tracker | |
| 10:44:01 | sean-k-mooney | i guess it will just stay there | |
| 10:44:09 | sean-k-mooney | ok ill review what you have later anyway | |
| 10:44:20 | sean-k-mooney | since you have a patch for the case i was really worried about | |
| 10:45:27 | sean-k-mooney | but ya until we have allocations it really does not matter anyway | |