| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-03-17 | |||
| 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 | |
| 17:23:50 | dansmith | I haven't actually done it yet (because I haven't decided about the signaling) but it's basically in the same place where it just adds them all up and decides if it's over.. it would actually be worse to (try to) fix it for one and not the other I think | |
| 17:24:13 | dansmith | I thought we were arguing over the meaning of "over-subscribed" and whether total=1,used=1,reserved=1 was "over-subscribed"? :) | |
| 17:25:53 | gibi | I think both is oversubscribed but they are different situations. I tink the reserved=used case is more of an allowed over subscription as nova managed VMs are not using more resources that available. The used > total case is different as it means nova VMs are using more than they should | |
| 17:26:14 | dansmith | yes, very much agree.. I thought that was the nit you were picking | |
| 17:26:24 | dansmith | or rather, | |
| 17:26:33 | dansmith | that you were suggesting something other than the above definition | |
| 17:27:07 | gibi | so I don't want to signal in this spec that we will allow used > total during move operation in the future as I'm nost sure we should allow nova-compute to even start with such config in the first pl.ace | |
| 17:28:17 | dansmith | okay I'm super confused | |
| 17:28:20 | dansmith | gmeet? :) | |
| 17:28:36 | dansmith | or tomorrow, if it's late for you | |
| 17:29:04 | gibi | we can have a quick gmeet I started my day late so I'm planned to be around longer | |
| 17:29:28 | dansmith | meet.google.com/njh-oqjw-azk | |
| 18:02:39 | opendevreview | Dan Smith proposed openstack/nova-specs master: Add one-time-use-devices spec https://review.opendev.org/c/openstack/nova-specs/+/943486 | |
| 18:45:10 | opendevreview | Doug Goldstein proposed openstack/nova master: ironic: fix logging of validation errors https://review.opendev.org/c/openstack/nova/+/942019 | |
| 19:18:26 | mikal | Morning | |
| 19:42:04 | opendevreview | Balazs Gibizer proposed openstack/nova master: Reproduce bug/2098496 https://review.opendev.org/c/openstack/nova/+/941673 | |
| 19:42:05 | opendevreview | Balazs Gibizer proposed openstack/nova master: Ignore metadata tags in pci/stats _find_pool logic https://review.opendev.org/c/openstack/nova/+/944277 | |
| 19:45:01 | opendevreview | Balazs Gibizer proposed openstack/nova master: Ignore metadata tags in pci/stats _find_pool logic https://review.opendev.org/c/openstack/nova/+/944277 | |
| 22:04:20 | opendevreview | Doug Goldstein proposed openstack/nova master: ironic: fix logging of validation errors https://review.opendev.org/c/openstack/nova/+/942019 | |
| #openstack-nova - 2025-03-18 | |||
| 08:12:14 | bauzas | gibi: could you give a swing for the prelude ? https://review.opendev.org/c/openstack/nova/+/944713 | |
| 08:12:58 | gibi | bauzas: sure | |
| 08:13:05 | bauzas | ta | |
| 08:16:22 | gibi | bauzas: could you quickly respin it to change vif mode to vif model? | |
| 08:16:35 | gibi | I can proxy dansmith's +2 and land it afterwards | |
| 08:17:21 | bauzas | gibi: sure | |
| 08:17:46 | bauzas | we still are awaiting the QEMU version bump to land before we tag RC1 | |
| 08:18:00 | bauzas | hopefully today we can branch :) | |
| 08:19:11 | opendevreview | Sylvain Bauza proposed openstack/nova master: Add Epoxy prelude section https://review.opendev.org/c/openstack/nova/+/944713 | |
| 08:22:55 | gibi | bauzas: thanks, approved the prelude | |
| 08:25:11 | bauzas | ty | |
| 08:27:25 | bauzas | Uggla: I forgot that you're now the PTL in projects.yaml so I can't longer automatically have a PTL-Approved label in Gerrit, can you please +1 again https://review.opendev.org/c/openstack/releases/+/943801 ? | |
| 08:28:17 | Uggla | Hello bauzas, done | |
| 08:28:20 | bauzas | ty | |
| 08:28:44 | bauzas | I'll start to modify the paperwork documentation for the new PTL :) | |
| 08:29:15 | Uggla | cool | |
| 08:29:27 | bauzas | once https://review.opendev.org/c/openstack/releases/+/943941, you'll be the new PTL :) | |
| 08:31:34 | bauzas | Uggla: could you please +1 https://review.opendev.org/c/openstack/releases/+/943947 ? | |
| 08:32:32 | Uggla | done as well | |
| 08:44:32 | bauzas | fun, can't log into the openstack wiki | |
| 08:44:35 | bauzas | anyone else ? | |
| 08:47:35 | Uggla | bauzas, same for me apparently | |
| 08:47:52 | bauzas | I left a ping in #openstack-infra | |
| 08:48:02 | Uggla | bauzas, nop it is slow but ok | |
| 08:48:26 | bauzas | we should move the wiki pages to the nova internal docs eventually, and just leave the meeting agenda as an etherpad | |
| 08:48:50 | bauzas | no need for us to continue to run a wiki | |
| 08:49:08 | gibi | for me it is not slow but actually not log in just put me back to where I started the login process | |
| 08:49:14 | bauzas | and many times it's either slow or broken | |
| 08:49:23 | bauzas | gibi: same behaviour here | |
| 08:50:03 | bauzas | I'm no longer a PTL but I have time :) | |
| 08:51:31 | Uggla | login is working but it is very sloooow. | |
| 09:25:48 | opendevreview | OpenStack Release Bot proposed openstack/placement stable/2025.1: Update .gitreview for stable/2025.1 https://review.opendev.org/c/openstack/placement/+/944840 | |
| 09:25:51 | opendevreview | OpenStack Release Bot proposed openstack/placement stable/2025.1: Update TOX_CONSTRAINTS_FILE for stable/2025.1 https://review.opendev.org/c/openstack/placement/+/944841 | |
| 09:25:53 | opendevreview | OpenStack Release Bot proposed openstack/placement master: Update master for stable/2025.1 https://review.opendev.org/c/openstack/placement/+/944842 | |
| 10:06:16 | opendevreview | Merged openstack/nova master: Add Epoxy prelude section https://review.opendev.org/c/openstack/nova/+/944713 | |
| 12:43:46 | opendevreview | Merged openstack/nova master: Bump MIN_{LIBVIRT,QEMU} for "Epoxy" https://review.opendev.org/c/openstack/nova/+/942871 | |
| 12:44:39 | frickler | \o/ | |
| 12:48:04 | opendevreview | Merged openstack/placement stable/2025.1: Update .gitreview for stable/2025.1 https://review.opendev.org/c/openstack/placement/+/944840 | |
| 12:59:41 | opendevreview | Merged openstack/placement stable/2025.1: Update TOX_CONSTRAINTS_FILE for stable/2025.1 https://review.opendev.org/c/openstack/placement/+/944841 | |
| 12:59:43 | opendevreview | Merged openstack/placement master: Update master for stable/2025.1 https://review.opendev.org/c/openstack/placement/+/944842 | |
| 13:57:28 | gibi | bauzas: FYI this is the PCI in Placement fix we discussed before in our planning. https://review.opendev.org/q/topic:%22bug/2098496%22 Dan is already +2. I know that we are in the RC quite period so I'm just asking for review, but I'm OK to keep this open until the final release and then land it on master and backport to stable 2025.1 | |
| 13:57:36 | gibi | no need for an RC2 just for this | |
| 14:04:37 | dansmith | bauzas: it's pretty nasty since it consumes more PCI devices than the user asked for, so we definitely need to backport that if no rc2 | |
| 14:05:07 | dansmith | usually the justification for an rc2 is that it fixes a regression that would be in this release.. gibi when did this bug get introduced do you know? | |
| 14:05:14 | dansmith | I assume before this cycle | |
| 14:18:03 | bauzas | we haven't yet branched RC1, so we could potentially merge it in time for RC1, but is that worth it ? | |
| 14:18:13 | bauzas | sorry, was in meeting... | |
| 14:18:39 | gibi | dansmith: before this cycle | |
| 14:18:44 | gibi | around Antelope | |
| 14:18:57 | bauzas | I really wanted to tag RC1 today, and mostly everything is done merged | |
| 14:19:08 | bauzas | even https://review.opendev.org/c/openstack/nova/+/942871/2 | |
| 14:19:33 | bauzas | so technically, I was about to propose a revision for nova RC1 https://review.opendev.org/c/openstack/releases/+/943941 | |
| 14:19:41 | dansmith | gibi: ack, so no new regression if we wait and backport | |
| 14:19:43 | gibi | bauzas: feel free to go and cut RC1. I can take care of this landing very early in F and backport it to E | |
| 14:19:51 | gibi | dansmith: yepp | |
| 14:19:54 | gibi | nothing new | |
| 14:19:58 | dansmith | bauzas: do eet | |
| 14:20:11 | bauzas | okay, then I'll set a new revision and let RC1 go | |
| 14:20:17 | gibi | cool | |
| 14:20:35 | bauzas | we're not that bad this cycle, we're only 4 days behind the original schedule :) | |
| 14:21:00 | gibi | :) | |
| 14:21:14 | gibi | the schedule was too early ;) we are ready when we are ready | |
| 14:21:32 | dansmith | that's not very agile :) | |