| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-09-09 | |||
| 08:36:01 | mhen | Uggla: can you assist me with this? is there a PTG etherpad for Nova to register sessions? | |
| 08:36:21 | mhen | (I will also talk to Cinder in their meeting today) | |
| 08:39:06 | Uggla | mhen, sure I can help to discuss that, no pb. I have not created the ptg etherpad page for Indri. | |
| 08:40:03 | Uggla | mhen, I will create the page today and ping you. So you will be able to enter the topic | |
| 08:40:32 | mhen | Uggla: splendid, thank you! | |
| 08:48:18 | Uggla | mhen, https://etherpad.opendev.org/p/nova-2027.1-ptg (a bit raw at the moment), but please add your topic at the bottom and I will schedule it for the vPTG. | |
| 10:25:03 | stephenfin | Uggla: a reminder that we're still waiting on your ack on https://review.opendev.org/c/openstack/project-config/+/988094/3 | |
| 11:15:43 | mhen | Uggla: thanks, I have added the cross-project session description to the bottom | |
| 11:37:46 | gibi | amorin: replied in your doc patches | |
| 12:05:21 | amorin | ack thanks! | |
| 12:07:33 | opendevreview | Arnaud Morin proposed openstack/nova master: Add pyroute2 in doc dependencies https://review.opendev.org/c/openstack/nova/+/1004781 | |
| 12:08:03 | gibi | amorin: if we miss the RC1 deadline with this I would not sweat on it much and just fix it on master and backport as soon as the GA is out and then push a point release if needed from stable | |
| 12:08:44 | gibi | but feel free to disagree if this somehow creates an ackward situation productifying the GA | |
| 12:08:52 | gibi | Uggla: can arrange for an RC2 if it is warranted | |
| 12:08:59 | gibi | s/:// | |
| 12:09:29 | amorin | I do not care that much on my side, I was just surprised that the doc was wrong. I may not be the only one, so better trying to have this before the GA IMHO | |
| 12:17:15 | gibi | ack | |
| 12:32:09 | opendevreview | Balazs Gibizer proposed openstack/nova master: Reproduce bug 2166786 https://review.opendev.org/c/openstack/nova/+/1004658 | |
| 12:46:09 | opendevreview | sean mooney proposed openstack/nova master: move nova-alt-config to debian-13 https://review.opendev.org/c/openstack/nova/+/966479 | |
| 13:15:52 | opendevreview | Stephen Finucane proposed openstack/placement master: tox: Use constraints option https://review.opendev.org/c/openstack/placement/+/996893 | |
| 13:15:53 | opendevreview | Stephen Finucane proposed openstack/placement master: Replace license classifier https://review.opendev.org/c/openstack/placement/+/1004422 | |
| 13:15:53 | opendevreview | Stephen Finucane proposed openstack/placement master: Migrate requirements to pyproject.toml https://review.opendev.org/c/openstack/placement/+/1004423 | |
| 13:17:24 | Uggla | stephenfin, I have just +1 the change above, sorry for the latency. | |
| 13:42:04 | gibi | Uggla: finally back to https://review.opendev.org/c/openstack/nova/+/999977/ I left some small suggestion inline but it is looks good pretty good now | |
| 13:43:18 | Uggla | gibi, thanks I will look at that. | |
| 14:12:13 | gibi | Uggla: also left some comments in the RC1 etherpad about api microversion history and prelude I guess those are still needs to be done | |
| 14:17:09 | Uggla | gibi, regarding prelude as it is a copy of highlight, I was waiting the HL to be settled which is the case now, so I'll create it. Thanks for the microversion history because I thought it was ok but missed it. | |
| 14:18:03 | gibi | cool | |
| 14:18:13 | gibi | I think the rest looks good | |
| 14:20:04 | opendevreview | Merged openstack/nova-specs master: Move Hibiscus implemented specs https://review.opendev.org/c/openstack/nova-specs/+/1004442 | |
| 15:01:09 | gibi | Uggla: left feedback on https://review.opendev.org/c/openstack/nova/+/999978 I think this evac bug and my evac bug discussed on the Monday call are sharing a root case. I left suggestion how to combine the two fixes that is non-controversial from the Monday discussion perspective but probably useful for both bugs. It is pretty complicated so feel free to ask me to jump on a call to explain more | |
| 15:05:01 | bauzas | gibi: I guess we won't have eventlet meeting, right? | |
| 15:07:21 | Uggla | gibi, yeah I had the feeling that Monday topic was more or less linked and that a 2 steps approach is required. One short term to meet customer happy and one longer term for the PTG. | |
| 15:15:30 | opendevreview | ribaudr proposed openstack/nova master: Mark 2.104 as maximum API version for 2026.2 Hibiscus https://review.opendev.org/c/openstack/nova/+/1004872 | |
| 15:22:35 | gibi | bauzas: it is ongoing but nothing important there | |
| 15:27:44 | dansmith | gmaan: sorry I just realized I never replied on your task leak thing | |
| 15:30:39 | Uggla | Reminder: upstream triage (https://meet.google.com/zjr-rxus-hzj) | |
| 15:31:36 | gibi | couple of mintues lte | |
| 15:31:37 | gibi | late | |
| 15:39:32 | opendevreview | Grzegorz Grasza proposed openstack/nova master: Match fixed_ip literally instead of partially escaping it as a regex https://review.opendev.org/c/openstack/nova/+/1004878 | |
| 16:28:15 | opendevreview | Clif Houck proposed openstack/nova stable/2026.1: perf(ironic): eliminate O(N²) ProviderTree deepcopy at startup https://review.opendev.org/c/openstack/nova/+/1004890 | |
| 16:37:22 | opendevreview | Merged openstack/placement master: tox: Use constraints option https://review.opendev.org/c/openstack/placement/+/996893 | |
| 16:43:00 | dansmith | gibi: are you still around/ | |
| 16:52:07 | gmaan | dansmith: thanks for reply, reading | |
| 16:52:24 | dansmith | gmaan: I'm curious what gibi thinks about this | |
| 16:52:37 | dansmith | wondering if he was already okay with the RPC breakage or didn't realize when he +2d | |
| 16:53:52 | gmaan | dansmith: I think he mentioned about the revert if it fails but not specific to new vs old node | |
| 16:54:13 | dansmith | I know | |
| 17:03:41 | opendevreview | Clif Houck proposed openstack/nova stable/2025.2: perf(ironic): eliminate O(N²) ProviderTree deepcopy at startup https://review.opendev.org/c/openstack/nova/+/1004899 | |
| 17:05:52 | gmaan | dansmith: I think, adding a new RPC call (end_tracked_task or something) will be better here with RPC version bump. do you want me change that way or wanted to wait for gibi reply? | |
| 17:06:50 | dansmith | I guess I'd rather not have a new call just for the very rare "cancel before started" case... why do you like that better? | |
| 17:06:52 | gmaan | that is what i was thinking to bump the RPC for either change but was not sure if we can do the version bumo at this stage or not. if yes then no issue | |
| 17:07:26 | gmaan | dansmith: it will not cancel before started, it can check if task is recorded otherwise log warning | |
| 17:07:40 | dansmith | it's not great to bump for either for sure at this point | |
| 17:08:06 | dansmith | gmaan: it's a cancel to the destination because we basically never started the migration which now doesn't need to be cleaned up right? | |
| 17:08:12 | gmaan | I am thinking it generic way where this common RPC call can be used in other place, because I am not sure we handle all cases of error on each node for cross-node operations | |
| 17:08:13 | dansmith | bauzas: are you still around? | |
| 17:08:22 | bauzas | I am | |
| 17:08:34 | dansmith | bauzas: can you skim this? https://review.opendev.org/c/openstack/nova/+/1003386 | |
| 17:09:00 | dansmith | just looking for another opinion.. I don't really like either option but they both require an RPC bump to fix (or we just ignore this case and leave it as a delayed shutdown bug I guess) | |
| 17:10:03 | bauzas | hah, ok, I can try to take a look but I don't have a lot of context for now | |
| 17:10:53 | gmaan | dansmith: but if rollback happening on source then it means migration started in dest right? | |
| 17:11:32 | dansmith | gmaan: started in nova but probably not libvirt yet right? | |
| 17:11:55 | gmaan | yes not till libvirt | |
| 17:12:35 | bauzas | wait | |
| 17:12:45 | bauzas | now I have a bit more of knowledge | |
| 17:13:16 | bauzas | all of the skim is for _post_live_migration, ie. once the instance is either fully migrated or rollbacked | |
| 17:13:30 | dansmith | actually, I guess not... it's any shared storage migration, even if it has already started | |
| 17:13:50 | bauzas | because we know we have remnants to cleanup, we have to modify the other compute to remove them | |
| 17:14:43 | dansmith | right, that's the case where we _do_ make the call | |
| 17:14:50 | dansmith | but the bug is in cases where we don't | |
| 17:15:14 | dansmith | as of the graceful shutdown stuff, we _always_ need to make the (or a) call to the dest because we left a pending task if nothing else | |
| 17:15:31 | bauzas | https://github.com/openstack/nova/blob/d3a1c95d06c2d97368207c2728fc262796683ad8/nova/compute/manager.py#L10557 | |
| 17:15:45 | dansmith | so to me the right solution is to always make that call in the future and pass it the cleanup flag maybe, but we can only do that with a version bump | |
| 17:15:46 | bauzas | all of that is in _post_live_migrate | |
| 17:15:57 | dansmith | else we will ask n-1 computes to do a cleanup when there is none to do | |
| 17:16:41 | gmaan | its during cleanup of pre live migration not post | |
| 17:16:56 | dansmith | right | |
| 17:17:21 | dansmith | well, during cleanup of live migration... to clean up what was started in pre_live_migration | |
| 17:17:25 | bauzas | https://docs.openstack.org/nova/latest/reference/live-migration.html | |
| 17:17:33 | gmaan | dansmith: yeah, that is my preference too when i proposed change, if we can delay this bug and mentioned as known bug and in part-2 we can handle by flag or new call | |
| 17:17:57 | gmaan | dansmith: yes -> 'to clean up what was started in pre_live_migration' | |
| 17:18:08 | dansmith | bauzas: just to be clear, I'm looking for opinions on if we can/should bump the compute RPC to add this call/param right now, just before rc1 | |
| 17:19:34 | bauzas | we're changing the live-migration workflow per se, not exactly the RPC interface | |
| 17:19:48 | bauzas | so that's kind of a grey area | |
| 17:20:03 | bauzas | but in case of a rolling upgrade, we have to ensure we're not breaking for sure | |
| 17:20:18 | dansmith | huh? | |
| 17:20:24 | bauzas | because old compute could expect a different workflow | |
| 17:20:27 | dansmith | it's 100% an RPC change :) | |
| 17:21:08 | gmaan | yeah, old dest will always do the rollback at dest when not needed and most probably fail | |
| 17:21:15 | bauzas | we don't change the RPC parameters for sure, but we changing the callers yes | |
| 17:21:17 | dansmith | not only are we expecting the new behavior of canceling the task, we need to be passing a parameter to instruct the old side not to try to clean up something it shouldn't be cleaning up | |
| 17:21:33 | dansmith | bauzas: we _need_ to add a parameter | |
| 17:21:51 | bauzas | lemme explain it differently | |
| 17:21:53 | gmaan | dansmith: flag can be avoided as as current code change where dest can calculate the cleanup is required or not | |
| 17:21:57 | dansmith | right now this will just generate (we think) a traceback | |
| 17:22:31 | bauzas | either we consider the existing patch good and then I have a concern due to rolling upgrades (old computes may expect the calls differently), or we assume we need to pass a new param and then I have concern witth a late RPC change | |
| 17:23:03 | dansmith | gmaan: but the flag also gives us the indication that we're making the new call so we can avoid doing it on the older versioon | |
| 17:23:03 | bauzas | either way, I'm not happy with such behavioural change so close to the release | |
| 17:23:48 | dansmith | bauzas: I don't think I'm okay with no bump and either change | |