| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-06-18 | |||
| 14:59:10 | Vii | look: https://bugs.launchpad.net/nova/+bug/2114913 | |
| 15:00:26 | Vii | creating an instance from horizon also fails | |
| 21:28:32 | opendevreview | Ghanshyam proposed openstack/nova master: Add Project Manager role context in unit tests https://review.opendev.org/c/openstack/nova/+/941056 | |
| #openstack-nova - 2025-06-19 | |||
| 09:41:03 | jlejeune | hello, I'm also impacted by that bug : https://bugs.launchpad.net/nova/+bug/2084238, do you know if someone begin to work on it ? | |
| 10:03:55 | jlejeune | I confirm that a request-id is set for new instances (created after migration to 2023.1) but that field stays at NULL for instances created before the migration | |
| 10:03:57 | gibi | jlejeune: I don't know about any work on that | |
| 10:04:30 | jlejeune | ok thanks, maybe it's something the migration tools should take care | |
| 10:05:04 | jlejeune | to fill random request-id in for allocated devices | |
| 10:12:50 | gibi | jlejeune: i don't have the time to dig into it right now. But I think this is a valid bug that needs to be fixed | |
| 14:10:44 | opendevreview | ribaudr proposed openstack/nova master: Fix bug 2114951 https://review.opendev.org/c/openstack/nova/+/952895 | |
| 14:10:44 | opendevreview | ribaudr proposed openstack/nova master: Reproducer for bug 2114951 https://review.opendev.org/c/openstack/nova/+/952894 | |
| 14:33:01 | opendevreview | Andriy Kurilin proposed openstack/nova master: Reuse 'detail:get_all_tenants' policy in server get api https://review.opendev.org/c/openstack/nova/+/952896 | |
| 14:57:13 | sean-k-mooney | the request_id fucntionalty was added a very very long time ago | |
| 14:58:36 | sean-k-mooney | jlejeune: this feels like you skipped runnign an online data mighration | |
| 14:59:54 | sean-k-mooney | oh the one i was thinking of was a diffent fild https://github.com/openstack/nova/blob/master/nova/cmd/manage.py#L221 | |
| 15:00:05 | sean-k-mooney | its the uuid on the device not the requst id | |
| 15:01:22 | jlejeune | sean-k-mooney: exactly | |
| 15:02:31 | sean-k-mooney | the request id should alwasy be set in recent version of openstack | |
| 15:03:13 | sean-k-mooney | it was added 11 years ago | |
| 15:03:54 | elodilles | sean-k-mooney: sorry for pinging you directly but you already reviewed the patch on master branch o:) could you please take a quick look/review on the stable/* backports of this patch? https://review.opendev.org/q/I56705bce8ee4354cd5cb1577a520c2d1c525f57b | |
| 15:03:59 | jlejeune | in recent version, yes it's filled, but not on stein release for example | |
| 15:04:31 | sean-k-mooney | jlejeune: it soudl have been there in stein too | |
| 15:04:49 | jlejeune | sean-k-mooney: hm | |
| 15:05:28 | jlejeune | it's not the case a t all | |
| 15:05:34 | sean-k-mooney | elodilles: sure | |
| 15:05:48 | elodilles | sean-k-mooney: o// thanks in advance! | |
| 15:09:13 | sean-k-mooney | the filed is nullable, when the reques is form a neuton port the request id is the neutron port uuid i belvie | |
| 15:09:17 | jlejeune | sean-k-mooney: indeed, the request_id field has been added 11 years ago | |
| 15:09:41 | jlejeune | I don't understand why it's null in my situation | |
| 15:09:42 | sean-k-mooney | when the request sorce is the flavor i belive it is expecte dto be null but i woudl have to dig itno this in detail | |
| 15:10:12 | sean-k-mooney | well there is request id and requeter_id | |
| 15:10:30 | sean-k-mooney | your speicificly asking about request.request_id) | |
| 15:11:39 | sean-k-mooney | the requester id is the one that hold the neutron port butalso backfil the request_id with a new uuid when we do that | |
| 15:13:37 | sean-k-mooney | jlejeune: is this a pci device related to a pci alis or a neutorn port | |
| 15:15:37 | jlejeune | to a pci alias | |
| 15:17:11 | sean-k-mooney | ack so the alisas was the older usage of this field as far as i recal which is whwere we woudl least expect to need ot back file | |
| 15:20:35 | sean-k-mooney | jlejeune: this is where it shoudl be generated https://github.com/openstack/nova/blob/64ca204c9cf497b0dcfff2d3a24b0dd795a57d1d/nova/pci/request.py#L261 | |
| 15:20:56 | sean-k-mooney | https://github.com/openstack/nova/commit/ccab6fed463337c029459469c76e92af3b96fa06 | |
| 15:28:36 | jlejeune | sean-k-mooney: ok, thanks for your commit, indeed I don't have backported it in my stein sources... that can explain | |
| 15:32:35 | sean-k-mooney | oh you did a feature backprot of the pic in placment code | |
| 15:32:49 | sean-k-mooney | ya this was new in zed | |
| 15:35:09 | jlejeune | ho there are a lot of missing commits: https://review.opendev.org/q/topic:%22bp/pci-device-tracking-in-placement%22 | |
| 15:35:42 | sean-k-mooney | it was a non triival feature which is why we did nto backport it downstream in redhat | |
| 15:35:48 | sean-k-mooney | well not the only reaon | |
| 15:36:16 | sean-k-mooney | we are actully still n the process of fully graducatign it to full support in our antelope based product | |
| 15:36:49 | sean-k-mooney | while the final QE works is happeing its "tech preview" althoug it does work | |
| 15:45:15 | sean-k-mooney | gibi: stephenfin: if ye have time for a very short patch please review https://review.opendev.org/c/openstack/nova/+/952306 to enable the memballon optimisation when you have time | |
| 15:45:50 | sean-k-mooney | Uggla: and when you have time can you mark https://blueprints.launchpad.net/nova/+spec/automatic-memballoon-freeing as approved | |
| 15:46:26 | Uggla | sean-k-mooney sure. | |
| 15:54:09 | opendevreview | Merged openstack/nova stable/2025.1: [tool] Fix backport validator for non-SLURP https://review.opendev.org/c/openstack/nova/+/951968 | |
| 16:07:13 | Uggla | sean-k-mooney I speak a bit too fast. I tracked your SLBP in the etherpad document as approved. But atm I can't set it in launchpad, I'm lacking rights to do it. So I'll set all approved SLBP as soon as I can. | |
| 16:11:21 | gibi | sean-k-mooney: is this memballon bp was approved? or you will bring it up for approval on the next nova meeting? | |
| 16:11:52 | gibi | my memories are vague | |
| 16:14:08 | Uggla | gibi, I approved it. | |
| 16:14:15 | Uggla | sorry I = we | |
| 16:18:49 | gibi | cool | |
| 16:18:51 | gibi | thanks | |
| 16:23:18 | opendevreview | Elod Illes proposed openstack/osc-placement master: DNM: gate health test https://review.opendev.org/c/openstack/osc-placement/+/952913 | |
| 16:24:10 | gibi | sean-k-mooney: left some questions in the patch. The impl looks good btw. | |
| 16:27:39 | opendevreview | Elod Illes proposed openstack/python-novaclient master: DNM: gate health test https://review.opendev.org/c/openstack/python-novaclient/+/952928 | |
| 16:31:38 | gibi | sean-k-mooney: FYI I think this will be the first use of the round robin placement a_c strategy out in the field https://bugs.launchpad.net/nova/+bug/2114947 | |
| 16:37:23 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for images APIs https://review.opendev.org/c/openstack/nova/+/952284 | |
| 16:37:24 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for volumes APIs https://review.opendev.org/c/openstack/nova/+/952348 | |
| 16:37:24 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Separate volume, snapshot and volume attachments https://review.opendev.org/c/openstack/nova/+/952347 | |
| 16:37:25 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for snapshots APIs https://review.opendev.org/c/openstack/nova/+/952349 | |
| 16:37:26 | opendevreview | Stephen Finucane proposed openstack/nova master: tests: Use valid UUIDs for cinder resources https://review.opendev.org/c/openstack/nova/+/952935 | |
| 16:37:26 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for volume attachments APIs https://review.opendev.org/c/openstack/nova/+/952350 | |
| 16:37:27 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Only apply "soft" additionalProperties validation to requests https://review.opendev.org/c/openstack/nova/+/952936 | |
| 16:41:55 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Correct expected errors https://review.opendev.org/c/openstack/nova/+/951640 | |
| 16:46:09 | sean-k-mooney | gibi: di it result in a bug or is it the fix for the bug | |
| 16:47:07 | sean-k-mooney | Uggla: i can set it as approved if you want in launchpad. at least in this case | |
| 16:47:48 | sean-k-mooney | updated https://blueprints.launchpad.net/nova/+spec/automatic-memballoon-freeing | |
| 16:48:23 | Uggla | sean-k-mooney, no it is ok, when I will be able to do it, I will check all approved SLBP and set them accordingly. | |
| 16:51:35 | sean-k-mooney | gibi: ah you saying it can be fixed by it, i think | |
| 16:51:35 | gibi | sean-k-mooney: they just hit the bug, I suggested to tune placement, we will see if this will help them | |
| 16:51:52 | gibi | the reporter is pretty responsive so hopefully we get feedback | |
| 16:52:10 | sean-k-mooney | cool | |
| 16:52:32 | sean-k-mooney | im not entirly sur if this is the same since it appears to hvae allcoated a device with the worng? resouce class | |
| 16:52:45 | gibi | which reminds me that we still not have upstream testing with breadth-first strategy due to the blocked devstack patch I have to go back to | |
| 16:53:05 | sean-k-mooney | oh they are not doing it properly | |
| 16:53:07 | gibi | sean-k-mooney: originally they had a config issue not having pci_in_placement enabled | |
| 16:53:16 | sean-k-mooney | wel | |
| 16:53:17 | gibi | now they enabled it and hitting timeout | |
| 16:53:25 | sean-k-mooney | they seam to have both a cutom trait and resouce class | |
| 16:54:03 | sean-k-mooney | device_spec = { "vendor_id":"10de", "product_id":"26b1", "address":"0000:4F:00.4", "resource_class":"CUSTOM_NVIDIA_RTX6000_ADA_48Q", "traits":"CUSTOM_NVIDIA_RTX6000_ADA_48Q", "managed":"no" } | |
| 16:54:19 | sean-k-mooney | they shoudl just be useign the reouces class not the triat | |
| 16:54:35 | sean-k-mooney | it wont break anything to have both | |
| 16:54:57 | gibi | yeah | |
| 16:55:05 | gibi | we can follow up with that once they see it working | |
| 16:55:41 | sean-k-mooney | but the other thing they are trying to do that kind fo unsupproted | |
| 16:56:05 | sean-k-mooney | is allcoatign mutlipel vFs | |
| 16:56:20 | sean-k-mooney | so these are gpus | |
| 16:56:33 | sean-k-mooney | and they are suing pci passthough to use the VFs | |
| 16:56:53 | sean-k-mooney | which i guess means they are trying to use the new way of doing vgpu that we added last cycle | |
| 16:57:07 | sean-k-mooney | with managed = no | |
| 16:57:24 | sean-k-mooney | but whiel you shoudl be able to have mulitpel devices in one vm | |
| 16:57:28 | sean-k-mooney | we have not actully tested that | |
| 16:58:10 | sean-k-mooney | i guess there is no really reason form a nova perspecitve why that woudl not work | |
| 16:58:20 | sean-k-mooney | we know it did o r does work for generic vfs | |
| 16:58:42 | sean-k-mooney | so the only reaosn for it not to work with gpus woudl eb due to a hardware/driver limitaiton | |