| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-02 | |||
| 12:46:30 | opendevreview | Balazs Gibizer proposed openstack/nova-specs master: Update the PCI in placement spec https://review.opendev.org/c/openstack/nova-specs/+/855218 | |
| 12:47:01 | gibi | sean-k-mooney, stephenfin: ^^ and this is the update of the Zed spec that sync the spec with the implementation | |
| 12:53:50 | sean-k-mooney | ok that passed unit test localy so it should be good | |
| 12:54:08 | sean-k-mooney | gibi: any prefernce on what i review first | |
| 12:54:19 | sean-k-mooney | gibi: i was goign to look at the code tehn the spec | |
| 12:54:29 | gibi | sean-k-mooney: any order is OK | |
| 13:06:00 | sean-k-mooney | stephenfin: one question i gues for you in https://review.opendev.org/c/openstack/nova/+/855186 or gibi | |
| 13:06:18 | sean-k-mooney | gibi: but the two followup look ok to me | |
| 13:06:24 | gibi | heh, that is a nice question | |
| 13:06:39 | gibi | I tried many ways to combine them and get a good looking result in the html | |
| 13:06:51 | sean-k-mooney | oh i guess i should look at that | |
| 13:06:59 | gibi | the current source produces the best html result for me | |
| 13:07:19 | gibi | but I'm curious if stephenfin has a better one | |
| 13:07:42 | gibi | for me reSt can be mistery sometimes | |
| 13:09:39 | opendevreview | Balazs Gibizer proposed openstack/nova-specs master: Re-propose PCI Device Tracking In Placement for A https://review.opendev.org/c/openstack/nova-specs/+/855661 | |
| 13:09:46 | sean-k-mooney | it looks alreight i guess https://717a5ffd6a01c6a737e0-3e7434681f5fe092d7172e763d28f5ee.ssl.cf5.rackcdn.com/855186/3/check/openstack-tox-docs/1737365/docs/admin/pci-passthrough.html | |
| 13:10:56 | sean-k-mooney | gibi: im going to delegate ot stepehn on this | |
| 13:11:02 | gibi | sure | |
| 13:11:36 | gibi | if there is a better way then I will change | |
| 13:12:02 | sean-k-mooney | i actully tough thte render was goign to be more dramatic then it is | |
| 13:12:08 | sean-k-mooney | like a note or imporant | |
| 13:12:15 | sean-k-mooney | this is pretty subtle | |
| 13:12:19 | bauzas | gibi: sorry if you felt abandoned for your PCI series | |
| 13:12:23 | sean-k-mooney | so i dont mind the duplicates as much | |
| 13:12:30 | bauzas | I didn't had time to look at all the merged changes | |
| 13:12:58 | opendevreview | Merged openstack/nova master: Generate request_id for Flavor based InstancePCIRequest https://review.opendev.org/c/openstack/nova/+/853835 | |
| 13:13:06 | sean-k-mooney | bauzas: you can make it up to gibi by looking at the unmerged once after RC1 :P | |
| 13:13:11 | gibi | bauzas: no worries, sean-k-mooney and stephenfin did an superb job providing feedback and reviews | |
| 13:16:16 | gibi | this was a lot of code (the whole series is over 8KLOC) and we merged a substantial and meaningful part of it | |
| 13:16:36 | sean-k-mooney | and fixed some latent bugs | |
| 13:16:44 | sean-k-mooney | hard to find ones at that | |
| 13:17:00 | sean-k-mooney | specificaly that decorator eating the excption | |
| 13:17:02 | gibi | yes, I was able to pull out some bugs in the process too. that was nice | |
| 13:17:51 | gibi | so while I'm sad that we could not land the whole thing in Zed, I think we made a good progress on something that was on our plate at least since 2019 | |
| 13:18:08 | sean-k-mooney | only 2019 | |
| 13:18:22 | sean-k-mooney | pci in placment is more or less why we started nested resouce providers | |
| 13:18:23 | gibi | I remember we whiteboarded it in China | |
| 13:18:34 | gibi | the rest is fading in my memory | |
| 13:18:52 | gibi | but sure there is a lot of history | |
| 13:19:03 | sean-k-mooney | yep | |
| 13:19:18 | sean-k-mooney | which make it niceer to see it finally making good progress | |
| 13:19:30 | sean-k-mooney | im happy with where we got to this cycle | |
| 13:22:24 | gibi | I afraid we will lose some momentum due to downstream priorities but I also hope I can land the existing patches in AA at least | |
| 13:22:58 | sean-k-mooney | gibi: did you see the patch that bauzas shared yesterday about the propsoed release schdule | |
| 13:22:58 | gibi | btw, I fixed the last kown bug of the scheduling part. | |
| 13:23:13 | sean-k-mooney | it also look like AA will be quite short | |
| 13:23:16 | gibi | sean-k-mooney: I saw | |
| 13:24:14 | gibi | I think we should focus on finishing in AA what we started in Z. like manial support, image encryption, PCI | |
| 13:24:39 | gibi | and commit only to a small number of small new features | |
| 13:24:41 | sean-k-mooney | yep same i was thinking that likely means that we should defer the neturon part to BB | |
| 13:25:00 | gibi | I will have no time to do significant work on the neutron part in AA timeframe | |
| 13:25:07 | gibi | so I agree | |
| 13:25:08 | sean-k-mooney | basiclaly this will need to get finsihed by mid decemerb | |
| 13:25:24 | gibi | jeez that is closer that I thought | |
| 13:25:38 | sean-k-mooney | ya so m2 is proposed as jan 4th | |
| 13:25:57 | sean-k-mooney | but i dont think we will have enough pepopel to merge stuff after decemebr 10th | |
| 13:26:03 | sean-k-mooney | many a littl latere | |
| 13:26:09 | sean-k-mooney | then FF woudl be febuary 14 | |
| 13:26:25 | sean-k-mooney | so about 6 week of time after the winder break | |
| 13:26:56 | sean-k-mooney | gibi: ideally i would hope we could merge the rest of the pci seriese by the end of septemeber or early october | |
| 13:27:18 | sean-k-mooney | but we will have to see how RC1 goes | |
| 13:28:02 | gibi | it is feature complete today :) (but to be honest how I store a list of RP UUIDs in InstancePCIRequest.extra_info might need a rework) | |
| 13:28:49 | sean-k-mooney | i have not looked at that bit yet | |
| 13:29:08 | gibi | https://review.opendev.org/c/openstack/nova/+/854121/13/nova/compute/utils.py#1537 | |
| 13:29:17 | sean-k-mooney | i was expecting the uuid in the device extra info column | |
| 13:29:19 | sean-k-mooney | but only one | |
| 13:29:21 | gibi | extra_infor is a dict of strings | |
| 13:29:31 | gibi | and I needed to store a list of UUIDs | |
| 13:29:37 | gibi | so I serialized /o\ | |
| 13:29:57 | gibi | one InstancePCIRequest might be fulfilled from a list of RPs | |
| 13:30:03 | gibi | due to count > 1 | |
| 13:30:39 | gibi | we need the mapping _before_ the PciDevice object is allocated to drive the selection | |
| 13:30:42 | sean-k-mooney | hum ill have to think about htat | |
| 13:30:46 | gibi | sure | |
| 13:31:03 | sean-k-mooney | i was epecting to be able to do a 1 :1 mappign of each request object to one rp uuid from the allocation | |
| 13:31:24 | sean-k-mooney | since we are going to split the flavor based allcoation into multipel request objects | |
| 13:31:30 | gibi | request group - RP is in 1:1 but I did not split InstancePCIRequest objects jut the RequestGroups | |
| 13:31:45 | sean-k-mooney | we shoudl split the object too i think | |
| 13:32:08 | sean-k-mooney | that way you can directly map each rest object to the group and allocation | |
| 13:32:46 | sean-k-mooney | is there a downside to doing that? at least for new code path | |
| 13:33:29 | sean-k-mooney | you dont need to answer that now just woth thinking about | |
| 13:33:48 | gibi | the stats module does many things per InstancePCIRequest today | |
| 13:34:04 | gibi | but it already handles that a single instance has multiple requests | |
| 13:34:35 | sean-k-mooney | yep it need to because of neutron and the fact we can have multiple differnt alaises | |
| 13:34:49 | sean-k-mooney | i think we can simplfy the code and basicaly alway have a count of 1 | |
| 13:35:10 | gibi | yeah , if we can split, then the count filed become unused | |
| 13:35:37 | sean-k-mooney | i think thats ok | |
| 13:35:39 | gibi | and some logic where we loop on request and the loop on count can be refactored to a single loop | |
| 13:35:54 | sean-k-mooney | we can drop it in a future version if we rev the object major version | |
| 13:36:52 | gibi | the only thing where we have to be careful is code that might did some affinity or block based decision based on a single request with count > 1 | |
| 13:37:11 | gibi | instead of doing it device by device | |
| 13:37:21 | gibi | the filter_pools code need to be checked | |
| 13:37:51 | sean-k-mooney | gibi: well it was ment to be per device today | |
| 13:38:00 | sean-k-mooney | so if it was per alias that would be a bug | |
| 13:38:16 | sean-k-mooney | i think you noted that the request could be fullfiled form differnt pools already | |
| 13:38:30 | sean-k-mooney | so hopefuly that all works | |
| 13:38:42 | sean-k-mooney | but soudn like more functional test can prove that one way or another | |
| 13:40:11 | gibi | yeah, I'm not afraid of the actual consumption part as that already needs to work per device as we can have multiple RP uuid per PCIreq in the current series | |
| 13:40:26 | gibi | this was my last fix btw ^^ | |
| 13:41:02 | sean-k-mooney | ah ok | |