| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-02-27 | |||
| 12:22:33 | sean-k-mooney | we will want to add 3.13 early next cycle | |
| 12:24:31 | stephenfin | and hopefully remove 3.9 | |
| 12:25:04 | tkajinam | hopefully though you may have to make sure that c9s is fully replaced by c10s in RDO | |
| 12:25:21 | stephenfin | indeed | |
| 12:25:31 | tkajinam | IIRC python 3.9 is the system python in c9s | |
| 12:26:04 | sean-k-mooney | 3.9 cant be removed until 2026.1 | |
| 12:26:22 | sean-k-mooney | we need to support both c9s and c10s in 2025.2 for upgrades | |
| 12:27:03 | tkajinam | you can make 2025.1 as the pivot between c9s and c10s I guess | |
| 12:27:28 | tkajinam | as we did for train | |
| 12:27:28 | sean-k-mooney | no becuase it was not aviable at the start of the 2025.1 cycle | |
| 12:27:29 | tkajinam | which may be better given some people may try direct upgrade from 2025.1 to 2026.1 | |
| 12:27:36 | sean-k-mooney | so its not in the officl testing runtimes for this release | |
| 12:27:44 | tkajinam | yeah that's the problem | |
| 12:27:50 | sean-k-mooney | the first tiem c10s can be added is 2025.2 | |
| 12:28:03 | tkajinam | there may be number of things we have to address such as redis->valkey | |
| 12:28:16 | sean-k-mooney | the other issus is | |
| 12:28:32 | sean-k-mooney | c10s is built with the x86_64v4 profile in gcc | |
| 12:28:42 | sean-k-mooney | meaning it wont run on the old rackspace cloud provider | |
| 12:29:15 | sean-k-mooney | so we will need to restrict the node set ot vexhost and the newer rax-flex cloud | |
| 12:29:25 | sean-k-mooney | maybe ovh but that will need testing to confirm | |
| 12:29:35 | stephenfin | sean-k-mooney: Could you look at https://review.opendev.org/c/openstack/placement/+/932399 and its predecessor? | |
| 12:29:50 | tkajinam | another fun transition :-P | |
| 12:29:51 | sean-k-mooney | oh finally yes | |
| 12:30:14 | tkajinam | I was only aware of complete migration to nmcli as a blocker. that's a good thing to know. | |
| 12:30:43 | sean-k-mooney | stephenfin: i tought i had a patch for this but your has a +2 so i dont even care if it id :) | |
| 12:31:58 | sean-k-mooney | stephenfin: hehe ya i did https://review.opendev.org/c/openstack/placement/+/899947 | |
| 12:32:09 | stephenfin | yup, and they both failed due to https://review.opendev.org/c/openstack/devstack/+/919581 | |
| 12:32:16 | stephenfin | or rather, because https://review.opendev.org/c/openstack/devstack/+/919581 wasn't in yet | |
| 12:32:51 | stephenfin | sean-k-mooney: wdywtd? I'm happy with either, seeing as they're identical | |
| 12:33:17 | sean-k-mooney | i already appoved yours | |
| 12:33:20 | stephenfin | ack | |
| 12:34:42 | stephenfin | sean-k-mooney: You're going to need to review https://review.opendev.org/c/openstack/placement/+/939637 too, I suspect, otherwise the py312 tests will fail | |
| 12:36:51 | sean-k-mooney | ... droping '' form the message | |
| 12:36:53 | sean-k-mooney | ok | |
| 12:37:41 | sean-k-mooney | we might want ot rewrite that test but teh current fix is ok | |
| 12:39:51 | tkajinam | stephenfin, do you have a min to review https://review.opendev.org/c/openstack/nova/+/939721 ? | |
| 12:39:59 | tkajinam | I thought I proposed it but I didn't it seems | |
| 12:41:09 | stephenfin | ack, done | |
| 12:42:02 | tkajinam | stephenfin, and another cleanup related to oslo https://review.opendev.org/c/openstack/nova/+/940619 | |
| 12:42:25 | tkajinam | stephenfin, thanks ! | |
| 12:49:09 | opendevreview | zhou zhong proposed openstack/nova master: Logging exception when query servers for further debug https://review.opendev.org/c/openstack/nova/+/942897 | |
| 12:53:28 | opendevreview | zhou zhong proposed openstack/nova master: Logging exception when query servers for further debug https://review.opendev.org/c/openstack/nova/+/942897 | |
| 12:55:29 | opendevreview | zhou zhong proposed openstack/nova master: Logging exception when query servers for further debug https://review.opendev.org/c/openstack/nova/+/942897 | |
| 13:15:04 | sean-k-mooney | tkajinam: by the way i had hoped to check in on your sev series earlier in the cycle but just never found time | |
| 13:15:34 | sean-k-mooney | tkajinam: i dropped my -1 adn agree with your arguemnt on defaulting to sev at least for now | |
| 13:15:56 | sean-k-mooney | tkajinam: i dont feel confidnet in being able to review it before FFs | |
| 13:16:31 | sean-k-mooney | tkajinam: but i would supprot tryign to focus on this early next cycle | |
| 13:18:11 | tkajinam | sean-k-mooney, thank you ! | |
| 13:33:52 | sean-k-mooney | just level settign with folks. while im not there yet im gettign close to my context swtiching limit so i likely wont have tiem to do many more reviews today at least not until i take a short break to reset | |
| 13:34:10 | sean-k-mooney | i see two feature that are clsoe to mergign that we might be able to get over the line | |
| 13:34:31 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/938604 and https://review.opendev.org/c/openstack/nova/+/938405 | |
| 13:34:59 | sean-k-mooney | so schduler hints in server show and the managed flag for pci passhtough | |
| 13:35:33 | sean-k-mooney | i will try to look at the follow up for pci live migratoin however im not sure ill have time to properly review that today but ill try | |
| 13:36:01 | gibi | ack | |
| 13:36:30 | gibi | the managed flag is approved going through the gate, the live-migratable series is under review by my at the moment | |
| 13:37:57 | sean-k-mooney | im too cold on the vtpm serices to meanining fully look at that today and honetly it has enough WIP patches that i dont think it viable currently | |
| 13:38:11 | sean-k-mooney | is there anything else i shoudl have on my radar or do you think those 3 are it | |
| 13:39:19 | sean-k-mooney | i dont consider bumping the min libvirt version to be a feature https://review.opendev.org/c/openstack/nova/+/942871 so i think that can merge between FF and rc1 | |
| 13:39:33 | sean-k-mooney | so im treating that as a lower priority | |
| 13:40:00 | gibi | yeah I think vtpm slips to F | |
| 13:40:52 | sean-k-mooney | ok im going to step away for 20 mins then and ill try an take a look at the migration series when i return | |
| 13:41:04 | gibi | while there are some raw edges in the live-migratable series it feels pretty close to me. I don't know how much brainpower bauzas has to look at that today | |
| 13:48:01 | bauzas | gibi: I'll look at it after some meeting | |
| 13:48:16 | gibi | ack (sending good wibes) | |
| 13:57:07 | tkajinam | I know everyone is busy but if you can spare some moments to review this specless bp then that'd be awesome https://review.opendev.org/c/openstack/nova/+/845660 | |
| 13:57:46 | tkajinam | I just rebased it to make sure it works with the latest code and likely need to leave before CI posts the latest result | |
| 13:58:05 | bauzas | tkajinam: my hard effort for today will be to purge the status etherpad and you're part of it :) | |
| 13:58:19 | tkajinam | \o/ | |
| 14:00:36 | tkajinam | this conflicts with the sev-es patches but I'm fine with pushing the sev-es work to next cycle and let that multipath change go first, given the complexity of sev-es series | |
| 14:01:46 | bauzas | thanks for telling the priorities | |
| 14:26:49 | opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Add new option to enforce multipath volume connections https://review.opendev.org/c/openstack/nova/+/845660 | |
| 14:29:06 | tkajinam | os-brick made a breaking interface change and that is part of the latest release. ugh | |
| 14:37:19 | opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Add new option to enforce multipath volume connections https://review.opendev.org/c/openstack/nova/+/845660 | |
| 15:01:07 | sean-k-mooney | tkajinam: looks like its small enough to add to the review list | |
| 15:01:14 | sean-k-mooney | for today | |
| 15:01:23 | sean-k-mooney | but i guess we will see | |
| 15:15:58 | sean-k-mooney | tkajinam: +2 with comments | |
| 15:16:20 | dansmith | tkajinam: I had a couple comments but didn't -1 | |
| 15:16:26 | dansmith | tkajinam: if you fix them I'll be +2+W | |
| 15:19:07 | bauzas | tkajinam: I have one concern https://review.opendev.org/c/openstack/nova/+/845660/15/nova/virt/libvirt/driver.py#1177 | |
| 15:19:08 | sean-k-mooney | dansmith: replied im not agaisnt InvalidConfiguration but it think its subtlly diffent | |
| 15:20:08 | bauzas | tkajinam: you were litterally speaking about how os-brick can break some API by a new major version, I'm a bit afraid of us pulling a hard dependency on some osbrick submodule at some driver initialization | |
| 15:20:32 | sean-k-mooney | dansmith: so if its updated im ok with that but i generally think of InvalidConfiguration as stricly configuring conflicting options or missign requried ones based on the current set values | |
| 15:21:09 | sean-k-mooney | dansmith: but i dont think i would be confused if this was InvalidConfiguration as an operator either | |
| 15:22:02 | dansmith | sean-k-mooney: I replied | |
| 15:22:51 | dansmith | bauzas: only if multipathd is configured as required and you could sidestep that problem by changing it to not if you had to for a package conflict | |
| 15:23:07 | dansmith | bauzas: to me, the more of this kind of stuff we delegate to brick (no matter where it is in their module hierarchy) the better | |
| 15:23:28 | dansmith | if they break their api and thus us, then so be it, like any other library | |
| 15:23:36 | bauzas | dansmith: sure, that's not the fact that we delegate to brick at startup | |
| 15:23:57 | bauzas | that's about calling a specific brick connector module to get that | |
| 15:24:01 | dansmith | it's that it's using a given driver | |
| 15:24:02 | sean-k-mooney | we also dont have a connecto obejct to use | |
| 15:24:11 | bauzas | while connectors do that already | |
| 15:24:12 | dansmith | sure, but the only thing that would break that should be a requirements change | |
| 15:24:14 | sean-k-mooney | we woud need to constract athat for a given voluem first | |
| 15:24:44 | bauzas | tbc, I haven't -1 the patch | |
| 15:24:51 | sean-k-mooney | bauzas: what i would prefer to do is add a privsep funciton in nova that just does what the current so brick funtion does | |
| 15:25:01 | bauzas | but I'm debating the alternatives, since I'm not at all a brick expert | |
| 15:25:07 | dansmith | sean-k-mooney: I'm very -1 on that | |
| 15:25:20 | bauzas | sean-k-mooney: sorry but I'm like dan | |