| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-12-08 | |||
| 16:41:28 | thill | Hello! Looking for additional feedback on this spec https://review.opendev.org/c/openstack/nova-specs/+/968065. Hoping to work through ideas/concerns to find a solution to our problem and it's proving to be a bit more difficult than anticipated. | |
| 18:35:31 | sean-k-mooney | thill: ignoring the detail of the spec for a minute teh spec freeze for this cycle was last thursday meaing that by defult this will have to be repropsoed for 2026.2 | |
| 18:37:29 | sean-k-mooney | in general usign teh nvoa user to allwo access to a resuce that a user could not otherwise use si privldage eslcaltion so allwoign a user to boot form a image they canot normally download is generally a security problem | |
| 18:38:31 | sean-k-mooney | the user can exfiltrate any data form teh image by just booting form a rescue image and copyint the block device or chreating a snapshot and download that | |
| 18:38:52 | sean-k-mooney | so im not really seaing a compleing reason to supprot booting from an image you cant download | |
| 19:01:35 | jgwentworth | sean-k-mooney: that's my thought on it as well ... if you can boot an instance from an image, you can effectively download the image. I appreciate that having to copy it is more difficult than being able to use the download API ... but the fact that the user can still effectively download it makes the idea of "can boot but cannot download" not so compelling to me either | |
| 19:38:13 | thill | Fair enough! I don't have any arguments against that logic at this point. I'll bubble this up and see what we want to do going forward. Thank you! | |
| 22:18:35 | opendevreview | Merged openstack/nova master: Use consistent program name for wsgi scripts and entry points https://review.opendev.org/c/openstack/nova/+/942605 | |
| 23:02:07 | JayF | Stable patch for Ironic 2024.2, already +2 from Elod, everything applied cleanly, if someone would help me land it'd be awesome: https://review.opendev.org/c/openstack/nova/+/969833 | |
| #openstack-nova - 2025-12-09 | |||
| 07:38:02 | opendevreview | Artem Vasilyev proposed openstack/nova master: Fix functional tests and mypy on macOS https://review.opendev.org/c/openstack/nova/+/937727 | |
| 09:31:41 | opendevreview | Merged openstack/nova master: Remove openSUSE/SLES from install guide https://review.opendev.org/c/openstack/nova/+/949324 | |
| 09:33:34 | opendevreview | Ivan Anfimov proposed openstack/nova master: doc: Enabling of using LibvirtDriver for compute node https://review.opendev.org/c/openstack/nova/+/939325 | |
| 09:33:39 | opendevreview | Ivan Anfimov proposed openstack/nova master: doc: Enabling of using LibvirtDriver for compute node https://review.opendev.org/c/openstack/nova/+/939325 | |
| 11:51:21 | opendevreview | Rajesh Tailor proposed openstack/nova master: Add functional reproducer for bug 2096884 https://review.opendev.org/c/openstack/nova/+/970238 | |
| 11:53:24 | DominikDanelski[m] | sean-k-mooney: Sorry, I wasn't on the other end of the discussion, so I'm not sure how it works. Are you normally notified on comments with replies that haven't been resolved by them? I refer to https://review.opendev.org/c/openstack/nova/+/969251/comment/7f85f631_a6a7fdbb/ Of course take your time, I only wanted to confirm that I've done it the right way. | |
| 11:55:04 | sean-k-mooney | DominikDanelski[m] so when yyou make the requeted change you shoudl mark it as done. if the ocmment is just geneal feedback but does not requrie a change you can mark it as acknolaged or you can reply and tick resolved in the ui to show the comment is nolonger relevnet | |
| 11:55:49 | sean-k-mooney | for that comment specificly i will get an emial when you updated the patch but not nessialy on a comment | |
| 11:56:15 | sean-k-mooney | the reason i asked you ot use a explcit flavor is its is not obvious why the excption should be raised without finding what the defualt flaovr is | |
| 11:56:51 | sean-k-mooney | you do not have any comment explainging that so as a review i woudl have to go digging intot hte test infra to know if the test should raise or not | |
| 11:57:31 | noonedeadpunk | hey folks. after upgrade to Epoxy I've started seing stack trace when attempting to create a gpu-passthrough instance, and I somehow link it to the https://opendev.org/openstack/nova/commit/78be1679312768383b684fa70ca4d2f5c4e35fa9#diff-8255edc78feecdbe2d14ab15e4580b4b6de916d2 | |
| 11:58:20 | noonedeadpunk | the problem is that self.roots is empty here: https://opendev.org/openstack/nova/src/commit/8a4b000216c7a6c2673af78d7eb7f9bf938dc867/nova/compute/provider_tree.py#L436 | |
| 11:59:40 | noonedeadpunk | from the placement view - resource provider is obviously there: https://paste.openstack.org/show/bn6ekRrWbg9ggNpuGx4h/ | |
| 11:59:59 | noonedeadpunk | But I get `ValueError: No such provider 623a0277-62e4-43bc-acae-964dab595905` on the nova-compute side as a result | |
| 11:59:59 | sean-k-mooney | self.roots is not refenced in teh commit you linked | |
| 12:00:13 | sean-k-mooney | it is used in the code but it is not in the changed code | |
| 12:00:36 | sean-k-mooney | noonedeadpunk: you dont have any downstream backprot do you? | |
| 12:00:51 | noonedeadpunk | no, I don't | |
| 12:00:52 | sean-k-mooney | it kind of soundsl like you mihgt have missed a patch | |
| 12:00:54 | sean-k-mooney | ack | |
| 12:01:07 | noonedeadpunk | but. stack trace goes through the new _remove_managed_rps_from_tree_not_in_view | |
| 12:01:09 | noonedeadpunk | https://paste.openstack.org/show/bqjIms96L7A7ODUPU33W/ | |
| 12:01:47 | sean-k-mooney | that does not refence self.roots either | |
| 12:02:11 | sean-k-mooney | do you have pci in placment enabled in this deployjment | |
| 12:02:29 | noonedeadpunk | Isn't that default? | |
| 12:02:34 | sean-k-mooney | no | |
| 12:02:49 | noonedeadpunk | jsut let me quick check.... | |
| 12:02:52 | sean-k-mooney | but once its enabled we dont support turning it off | |
| 12:03:08 | noonedeadpunk | I was quite sure it is | |
| 12:03:30 | noonedeadpunk | shoot | |
| 12:03:32 | noonedeadpunk | thanks | |
| 12:03:34 | noonedeadpunk | it was fast | |
| 12:03:38 | sean-k-mooney | we may have turned it on in the last release or so | |
| 12:03:42 | noonedeadpunk | I bet somebody has removed it... | |
| 12:03:52 | sean-k-mooney | but i dont know if we did that yet or not | |
| 12:04:02 | noonedeadpunk | I have report_in_placement = True but not pci_in_placement | |
| 12:04:16 | sean-k-mooney | still false https://docs.openstack.org/nova/latest/configuration/config.html#pci.report_in_placement | |
| 12:04:17 | noonedeadpunk | sorry for this stupid thing... | |
| 12:04:36 | sean-k-mooney | no thats actully the option that i wanted | |
| 12:04:40 | sean-k-mooney | so there are two part | |
| 12:04:52 | sean-k-mooney | on the compute you set report_in_placement = True | |
| 12:05:07 | sean-k-mooney | and in the schdluer you set the other flag to include it in the placment query | |
| 12:05:50 | sean-k-mooney | if you have report_in_placement=true it shoudl enabel this codepath but the error is basiclly saying it cant find the resouce provdier | |
| 12:05:50 | noonedeadpunk | Seems I don;t have override for `pci_in_placement` at all | |
| 12:06:10 | opendevreview | Lajos Katona proposed openstack/nova master: WIP: Use SDK for Neutron Ports https://review.opendev.org/c/openstack/nova/+/969298 | |
| 12:06:22 | noonedeadpunk | but if it's a scheduler part - scheduler seems to be able to find and supply the resource id | |
| 12:06:59 | noonedeadpunk | let me fix scheduler anyway... | |
| 12:07:10 | sean-k-mooney | noonedeadpunk: can you check if the resouce provider for that compute exists in placement | |
| 12:07:31 | noonedeadpunk | so the id of in the stack trace is a child | |
| 12:07:39 | noonedeadpunk | https://paste.openstack.org/show/bn6ekRrWbg9ggNpuGx4h/ | |
| 12:07:47 | sean-k-mooney | ack ya it shoudl be the chile for the pci device | |
| 12:08:04 | sean-k-mooney | right so its os-compute-gpu01-az2_0000:25:00.0 | |
| 12:08:12 | noonedeadpunk | yeah | |
| 12:08:16 | sean-k-mooney | the inventory for the gpu | |
| 12:08:37 | sean-k-mooney | so can you confirm that that is in you pci devspec and that the adress is correct | |
| 12:09:11 | noonedeadpunk | 25:00.0 3D controller: NVIDIA Corporation | |
| 12:09:14 | noonedeadpunk | from lspci | |
| 12:09:41 | sean-k-mooney | ya that looks normal | |
| 12:10:28 | sean-k-mooney | i belive self._remove_managed_rps_from_tree_not_in_view(provider_tree) is intended to be used to remove RP for pci device that are nolonger in the whitelist | |
| 12:10:48 | sean-k-mooney | so that is why i was suggestign checkign the devspec in the nova.conf on the compute to confirm that is correct | |
| 12:12:34 | sean-k-mooney | there could ligitimatly be a bug i just want to rule out config errors | |
| 12:13:15 | noonedeadpunk | so one thing I am suspicious about.... | |
| 12:13:47 | noonedeadpunk | Is that we have a custom trait on top of the resource class in there | |
| 12:14:00 | noonedeadpunk | and this custom trait is applied only to the root device | |
| 12:14:20 | noonedeadpunk | https://paste.openstack.org/show/bhtdPwgzYHpzCdoIGe32/ | |
| 12:14:24 | sean-k-mooney | am i dont think that shoudl break anythign but maybe | |
| 12:15:26 | noonedeadpunk | ah, well, it's passed to children as well | |
| 12:15:33 | sean-k-mooney | we shoudl be adding COMPUTE_MANAGED_PCI_DEVICE as well | |
| 12:15:39 | sean-k-mooney | can you check fi you see both? | |
| 12:16:38 | noonedeadpunk | yes, I see CUSTOM_GPU_PASSTHROUGH and COMPUTE_MANAGED_PCI_DEVICE traits on both parent and childs | |
| 12:16:48 | noonedeadpunk | but not the resource_class | |
| 12:17:05 | sean-k-mooney | well the resouce class shoul be the resouce class in the invetnotry | |
| 12:17:11 | noonedeadpunk | But resource class should not be in traits iirc | |
| 12:17:18 | sean-k-mooney | correct | |
| 12:17:27 | sean-k-mooney | if you do an inventory show on the rp you shoudl see it there | |
| 12:17:42 | noonedeadpunk | openstack resource class show CUSTOM_A10_FULL returns the name, yes | |
| 12:20:57 | noonedeadpunk | I kinda failing to understand at what point `self.roots_by_uuid` is expected to be populated | |
| 12:22:16 | sean-k-mooney | https://opendev.org/openstack/nova/src/commit/8a4b000216c7a6c2673af78d7eb7f9bf938dc867/nova/compute/provider_tree.py#L292 | |
| 12:22:17 | noonedeadpunk | it does not look like it's cached, or populated during instance create request | |
| 12:22:47 | noonedeadpunk | but according to trace it's not called? | |
| 12:22:50 | sean-k-mooney | it can be populated in othere wase too | |
| 12:23:10 | sean-k-mooney | the tace doe not actully show a specific error | |
| 12:23:20 | sean-k-mooney | just that the child rp was nto found | |
| 12:23:43 | sean-k-mooney | i assume this si repoabale i.e. if yuou restart the nova comptue agent it happens again | |
| 12:24:02 | noonedeadpunk | well, I used epdb, and self.roots is dict_values([]) | |
| 12:24:10 | noonedeadpunk | yes, sure | |
| 12:24:43 | sean-k-mooney | its returnnign the values mapping of the dict yes | |
| 12:25:17 | noonedeadpunk | and self.roots_by_uuid is {} | |
| 12:25:27 | sean-k-mooney | this shoudl be updated in memory as part fo init_host | |
| 12:25:31 | noonedeadpunk | so it feels that it's not populated in fact... | |
| 12:26:23 | sean-k-mooney | so during init_host we end up running update_aviable_resocues which populates the resouce tacker and caches the provieder tree | |