| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-02 | |||
| 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 | |
| 13:41:10 | sean-k-mooney | that was the bug | |
| 13:41:12 | frickler | gibi: sean-k-mooney: prettytable 3.4.1 was just releases which reverts the broken change. nova tests work fine for me with that locally. does one of you want to propose the exclude in reqs? | |
| 13:41:42 | gibi | frickler: if you already at it then feel free to propose the exclude | |
| 13:41:43 | sean-k-mooney | frickler: should we proceed with hardeing the nova code anyway | |
| 13:42:31 | sean-k-mooney | my patch works with 3.4.1 too it seams | |
| 13:43:05 | frickler | can't hurt to be on the safe side, then, I'd say | |
| 13:43:56 | sean-k-mooney | ok ill keep it open and backport it to yoga so | |
| 13:44:26 | sean-k-mooney | at least that way if a disto hits this issue or they make the chagne in 4.0 we will be fine | |
| 13:48:18 | frickler | now I only need to find out the path it get's pulled in, since it doesn't seem to be a direct dependency | |
| 13:52:58 | sean-k-mooney | frickler: PrettyTable ? | |
| 13:53:07 | sean-k-mooney | nova depend on it directly but i guess we might not list it | |
| 13:53:34 | sean-k-mooney | https://github.com/openstack/nova/blob/master/requirements.txt#L18 | |
| 13:53:38 | sean-k-mooney | its there | |
| 13:53:57 | bauzas | sean-k-mooney: I checked all the libs and we don't need a new release | |
| 13:54:01 | bauzas | did I miss one ? | |
| 13:54:35 | sean-k-mooney | we may want anotther release of python-novaclint | |
| 13:54:37 | sean-k-mooney | brb | |
| 13:54:45 | sean-k-mooney | if we merge some pending patches | |
| 14:02:20 | opendevreview | Slawek Kaplonski proposed openstack/nova master: WIP Don't provide MTU value in metadata service if DHCP is enabled https://review.opendev.org/c/openstack/nova/+/855664 | |