| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-03-14 | |||
| 17:33:45 | sean-k-mooney | we just dont test it | |
| 18:09:01 | sean-k-mooney | dansmith: im reluctantly +2 but +2 none the same on the one time use device spec | |
| 18:09:44 | dansmith | I will take a reluctant +2 over the alternative thanks :) | |
| 18:09:49 | sean-k-mooney | i lost that tab like 4 times today.... | |
| 18:11:03 | sean-k-mooney | dansmith: by the way you mentioned a crash when you used the qxl device to test this, you might have better luck with somethign like the random number generator or a virtio-blk device | |
| 18:11:32 | sean-k-mooney | or igb vfs if your qemu supports it | |
| 18:12:22 | sean-k-mooney | i have had better look with nic/block devices when palying with double passthough then graphics cards | |
| 18:12:33 | sean-k-mooney | not sure why but just my personal experince | |
| 18:14:17 | dansmith | yeah, no igb on this box's qemu but yeah I need to use a different device | |
| 18:14:34 | dansmith | honestly it reboots in seconds and I always need to restart nova services after each fail, so it hasn't been so bad :P | |
| 18:15:36 | sean-k-mooney | if you try e1000 instead i think that will work | |
| 18:15:57 | sean-k-mooney | it diefenly works with a doubel passthough of a phsyical e1000 nic but i think the virutal ones work too | |
| 19:13:04 | opendevreview | Dan Smith proposed openstack/nova master: Ignore metadata tags in pci/stats _find_pool logic https://review.opendev.org/c/openstack/nova/+/944277 | |
| #openstack-nova - 2025-03-16 | |||
| 02:23:46 | opendevreview | Takashi Natsume proposed openstack/nova master: Update contributor guide for 2025.2 Flamingo https://review.opendev.org/c/openstack/nova/+/944603 | |
| 13:36:37 | opendevreview | Takashi Kajinami proposed openstack/nova master: Fix description of [pci] alias https://review.opendev.org/c/openstack/nova/+/944611 | |
| 14:32:39 | IshanShanware[m] | sean-k-mooney:... (full message at <https://matrix.org/oftc/media/v1/media/download/AV6erZTaSkUc-1ptdYd_qKTJvrKZM-gcFd4g_bJVy6rXGULoskvXyHay2wXi9H0HKT8DjkWIuL9S_YoRXhpohZBCeV53gI0wAG1hdHJpeC5vcmcveVpPZUhSanJ3eFhCck52TXBrSVJFZklq>) | |
| 19:16:55 | Callum027 | sean-k-mooney: Looking at the agenda for the next meeting, kinda looks like it's still focusing on the current release and not planning for 2025.2. Should I add the image meta changes to the agenda for next week, or is this week fine? | |
| #openstack-nova - 2025-03-17 | |||
| 07:08:29 | r-taketn | hi. I have two entries for next PTG(About CCA, RDT/MPAM). Besides purchasing a ticket and submitting spec, what else should I prepare for the PTG? | |
| 08:03:56 | frickler | Uggla: could you have a quick look at https://review.opendev.org/c/openstack/releases/+/943801 pls? | |
| 09:19:58 | IshanShanware[m] | * sean-k-mooney:... (full message at <https://matrix.org/oftc/media/v1/media/download/Af0thDY-PzrHZLStDMYwU6GFaZIiMSA41JuprrmuPgJq6AY3dEeP8-2cHH70wc9rwy3S6QmtPw_bSYPSO95YLsdCeV64AjOgAG1hdHJpeC5vcmcvVUNuTVBJVllKcFlkQmR5bnhsc0V2Qllv>) | |
| 09:36:12 | frickler | Uggla: bauzas: also what's the status with rc1 for nova+placement? we're past the deadline now | |
| 09:36:43 | bauzas | frickler: as said in the nova rc1 patch, we're missing some patches before tagging | |
| 09:37:09 | bauzas | everything is tracked here https://etherpad.opendev.org/p/nova-epoxy-rc-potential | |
| 09:37:40 | bauzas | placement rc1 can be tagged tho, just double-checking the last dependencies | |
| 09:43:50 | frickler | bauzas: unless I miss something, the only remaining nova change is https://review.opendev.org/c/openstack/nova/+/943952 which is a pretty trivial but necessary change that keeps failing due to unrelated CI instability. let me know once you're ready to get this force-merged to unblock things :-) | |
| 09:44:29 | bauzas_ | frickler: not exactly, we're also missing a prelude patch that needs to be written as copy of the cycle highlights | |
| 09:45:02 | bauzas_ | that's a TODO on me this morning since we start to have a review quorum from the nova cores about the highlights | |
| 10:19:47 | opendevreview | Sylvain Bauza proposed openstack/nova master: Add Epoxy prelude section https://review.opendev.org/c/openstack/nova/+/944713 | |
| 11:29:10 | IshanShanware[m] | <IshanShanware[m]> "sean-k-mooney:..." <- bauzas: any thoughts here ? | |
| 12:14:46 | opendevreview | ribaudr proposed openstack/nova master: FUP improve comment accuracy and variable naming for tag removal https://review.opendev.org/c/openstack/nova/+/943124 | |
| 12:14:46 | opendevreview | ribaudr proposed openstack/nova master: FUP Remove unnecessary PCI check https://review.opendev.org/c/openstack/nova/+/944105 | |
| 12:14:47 | opendevreview | ribaudr proposed openstack/nova master: FUP improve and add integration tests for PCI SR-IOV servers https://review.opendev.org/c/openstack/nova/+/944106 | |
| 12:14:47 | opendevreview | ribaudr proposed openstack/nova master: FUP Add a warning to make non-explicit live migration request debugging easier https://review.opendev.org/c/openstack/nova/+/944133 | |
| 12:14:48 | opendevreview | ribaudr proposed openstack/nova master: FUP Update pci-passthrough and virtual-gpu documentation https://review.opendev.org/c/openstack/nova/+/944153 | |
| 13:45:54 | bauzas | cores, can we please give this a go ? https://review.opendev.org/c/openstack/nova/+/944713 | |
| 13:47:16 | dansmith | bauzas: I did three minutes ago | |
| 13:47:26 | bauzas | cool | |
| 13:49:28 | opendevreview | Sylvain Bauza proposed openstack/nova master: Add Epoxy prelude section https://review.opendev.org/c/openstack/nova/+/944713 | |
| 13:49:34 | bauzas | updated ^ | |
| 13:50:26 | dansmith | same | |
| 13:53:20 | dansmith | bauzas: wanna fix up that cycle highlights one too and I'll +2? | |
| 13:53:27 | bauzas | yup | |
| 13:54:16 | dansmith | bauzas: thanks for always being on top of these release things | |
| 13:54:32 | dansmith | uggla a de grandes chaussures à remplir | |
| 13:54:37 | bauzas | last time unless Uggla leaves me do that again in Flamingo :) | |
| 13:54:46 | bauzas | dansmith: lollylol | |
| 13:55:59 | bauzas | cycle highlights updated too | |
| 13:56:34 | dansmith | oh duh, I can't +2 that | |
| 13:56:41 | dansmith | sorry, but +1d :) | |
| 13:56:57 | opendevreview | Merged openstack/nova master: Update compute rpc alias for epoxy https://review.opendev.org/c/openstack/nova/+/943952 | |
| 13:57:53 | Uggla | @dansmith, you will learn French, that's a good start ! | |
| 13:58:21 | dansmith | I will not.. one french translation via google from me per cycle and that was the one for flamingo :) | |
| 13:59:28 | dansmith | the only one I really "know" is "voulez-vous coucher ... " you know the rest :) | |
| 13:59:31 | Uggla | @bauzas, I'll try to do it for flamingo, but I hope, you will be not far away to check it. ;) | |
| 14:00:49 | bauzas | Uggla: GMaps tells me a distance of 36 kms by road indeed | |
| 14:01:03 | Uggla | @dansmith, a useful one. ;) | |
| 14:01:58 | Uggla | bauzas, any chance you merge couple of FUP for vGPU before RC 1 ? | |
| 14:02:54 | dansmith | we're already late right? unless it's something critical I'd vote to stay the course, backport if it's important | |
| 14:05:21 | bauzas | Uggla: I'm a bit lost now, the bottom patches are on gate, but for the other 3 ones, there is a still -1 for the 3rd | |
| 14:05:54 | bauzas | Uggla: tbc, we can merge the two first as those are in the gate, but for the other ones, I don't think so unfortunately :( | |
| 14:07:45 | bauzas | if those two patches merge before we merge rc1, all good but I won't await them unfortunately | |
| 14:08:54 | Uggla | bauzas, the one for the doc is important. but it can be backported without pb. | |
| 14:09:05 | bauzas | yep, I know :( | |
| 14:10:09 | Uggla | I can put it down in the serie if it helps. | |
| 14:11:33 | Uggla | I have fixed the comments from @gibi and @sean-k-mooney, but it needs a review. Anyway let me know if I can help if not then we'll see and backport. | |
| 15:43:52 | dansmith | gibi: sorry to complicate the workflow with those grammar fixes. I was thinking I could +2 it after that and totally forgot about the TODOs, else I would have just left the comments | |
| 15:44:01 | gibi | no worries | |
| 15:44:26 | gibi | it easy to just pull the new ps from gerrit and continue from that | |
| 15:44:39 | dansmith | as long as no more changes were local, but yeah | |
| 15:45:04 | gibi | yeah I had no local changes to apply on top with a stash / stash pop | |
| 16:01:15 | dansmith | bauzas: fancy re-applying your +2 to this? https://review.opendev.org/c/openstack/nova-specs/+/943486 | |
| 16:16:28 | gibi | dansmith: left some comments in the spec | |
| 16:26:58 | dansmith | gibi: thanks, I totally see now why those migrate scenarios sound wrong, obviously not my intention :) | |
| 16:27:13 | gibi | cool | |
| 16:27:28 | dansmith | gibi: left a question for you on the evac thing, I don't have an easy way to test that locally, but I'm also not sure what you're worried about specifically | |
| 16:28:48 | gibi | dansmith: I feel evac is different but I need to take a look at the code to see how it is different... | |
| 16:29:46 | dansmith | gibi: okay did you want me to just mention that we need to look at that in the implementation or dig into the difference? I could *try* to set up something to test the evac but I'm not sure if I'll be able to squeeze it in | |
| 16:30:18 | gibi | I'm OK to mention evac as also probably affected and then later we can figure out what that really means | |
| 16:32:28 | dansmith | okay | |
| 16:33:04 | gibi | https://github.com/openstack/nova/blob/6b45672b23db47ccbf74dbda4f2678fd25ea22ed/nova/conductor/manager.py#L1325 the place conductor schedules the evac, but above it we have the old case where the evac is forced to a host and skipping the scheduler | |
| 16:33:50 | gibi | I'm not sure if we try to move the allocation to the migration uuid in either case | |
| 16:34:07 | dansmith | ah, okay, but probably the same principle applies here if you're in transition and don't have the PCI-i-p filter enabled such that we heal the allocation for it and the inventory right? | |
| 16:34:35 | dansmith | since we key the inventory reserved=1 off of the objects.PCIDevice and not the allocation, I think we'll reserve the device immediately regardless | |
| 16:35:30 | bauzas | maybe I misunderstood, but I was able to understand what "burned" was meaning | |
| 16:35:58 | bauzas | 'burned' to me means that this is reserved and you can't longer use this device unless you're able to unreserve it | |
| 16:36:30 | bauzas | so, of course, when evacuating something that was already reserved, we then also reserve the target | |
| 16:36:40 | bauzas | both then are 'burned' | |
| 16:36:45 | gibi | dansmith: my point is that if evac does not call move_allocations then evac operation will not be blocked by placement like cold/live migrate and resize that fails at move_allocations if reserved=1 | |
| 16:37:28 | dansmith | bauzas: I think the problem is I referred to "burned" in the early part as happening immediately, but I wrote the migration lifecycle stuff using burned to mean after the allocation was dropped.. it doesn't change what we're doing, it's just not cear | |
| 16:37:47 | dansmith | bauzas: I think we should say "burned happens as soon as reserved is incremented", thus instances run with a "burned" device the whole time.. that will be clearer | |
| 16:37:56 | bauzas | cool cool | |
| 16:38:11 | bauzas | fwiw, nothing changes to me, this is just a documentation question, hence why I +2d it | |
| 16:38:31 | bauzas | we can change the spec in a follow-up if that's really that | |
| 16:38:42 | dansmith | gibi: ah okay | |
| 16:38:53 | dansmith | bauzas: yep, I'm rephrasing now | |
| 16:38:54 | gibi | dansmith: maybe evac will just work out of the box | |
| 16:39:21 | gibi | dansmith: anyhow I can try evac at some point later this week with your WIP code | |
| 16:39:47 | gibi | so for the spec that mention that evac might or might not be effected by the placement bug and we can refine that later | |
| 16:39:55 | dansmith | gibi: ack will do | |
| 16:43:42 | gibi | thanks | |