| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-03-17 | |||
| 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 Remove unnecessary PCI check https://review.opendev.org/c/openstack/nova/+/944105 | |
| 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: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: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: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 | |
| 16:45:05 | dansmith | gibi: if the situation you described doesn't heal the allocations before we start the instance, then evacuation would be able to oversubscribe a host today, even without this I think right? | |
| 16:47:16 | gibi | I think the situation (i.e. not having move_allocation called) during evac, does not change the healing logic running on the destination compute. Hopefully it handles the fact that the instance uuid is allocating from two RP trees, one from the source node and one from the destination node | |
| 16:47:49 | gibi | but that problem preexists not otu specific | |
| 16:48:00 | gibi | * problem, if any | |
| 16:48:07 | opendevreview | Dan Smith proposed openstack/nova-specs master: Add one-time-use-devices spec https://review.opendev.org/c/openstack/nova-specs/+/943486 | |
| 16:48:40 | dansmith | gibi: since we call _update() synchronously in instance_claim() I think we *have* to be fixing the allocation before we start running the instance, and would fail if we couldn't | |
| 16:49:13 | dansmith | anyway, see if these ^ wording updates make it clearer | |
| 16:50:21 | gibi | dansmith: I think we are on the same page. The healing happnes regardless of move_alloction called or not in the conductor | |
| 16:50:44 | dansmith | ...and synchronously such that if it fails we fail, but definitely good to confirm | |
| 16:51:12 | gibi | yeah | |
| 16:51:19 | gibi | looking at the spec... | |
| 16:51:50 | dansmith | also, please clarify your "over-subscribed" comment.. perhaps it's just a meaning-of-the-phrase thing | |
| 17:10:57 | gibi | dansmith: ack, clarified in the reivew | |
| 17:11:00 | gibi | *review | |
| 17:15:28 | dansmith | replied.. I guess it's just what you think "over-subscribed" means... | |
| 17:21:17 | gibi | dansmith: do we want to fix both oversubscribed case in placement? | |
| 17:21:29 | gibi | or just the reserved=used case? | |
| 17:21:50 | dansmith | gibi: I'm not sure what you mean.. does placement define over-subscribed to mean something specific? | |
| 17:22:36 | gibi | dansmith: I just don't want to suggest we will fix both over-subscribed case in a later bugfix. I think we only want to fix the reserved=used case | |
| 17:23:05 | dansmith | it'll be the same fix I think | |