Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-09-02
20:20:47 opendevreview Merged openstack/nova master: Fix pci_tracker.save to delete all removed devs https://review.opendev.org/c/openstack/nova/+/953972
22:12:55 gmaan Uggla: commented in this, I am ok to fix this as bug and no need to bump microversion. I think you are planning to backport also https://review.opendev.org/c/openstack/nova/+/952895
22:13:13 gmaan some suggestion to fix comment and explain detail in commit msg otherwise fix lgtm
#openstack-nova - 2025-09-03
08:05:37 opendevreview ribaudr proposed openstack/nova master: Reproducer for bug 2114951 https://review.opendev.org/c/openstack/nova/+/952894
08:05:38 opendevreview ribaudr proposed openstack/nova master: Fix bug 2114951 https://review.opendev.org/c/openstack/nova/+/952895
08:25:03 opendevreview ribaudr proposed openstack/nova master: Add Flamingo prelude section https://review.opendev.org/c/openstack/nova/+/959188
10:00:15 opendevreview Tobias Urdin proposed openstack/nova master: Prevent leaking host info when HostMappingNotFound https://review.opendev.org/c/openstack/nova/+/959296
10:23:46 opendevreview ribaudr proposed openstack/nova master: Add Flamingo prelude section https://review.opendev.org/c/openstack/nova/+/959188
10:24:07 opendevreview Merged openstack/nova master: Fix duplicate words https://review.opendev.org/c/openstack/nova/+/959136
10:24:39 nate Hi ! I have a question regarding compute nodes and cinder volume encryption. We use a ceph backend with RBD with LUKS encrypted volume with encryption keys stored in barbican. At volume creation, the key belong to the end-user creating the volume. But our compute node, who has a dedicated compute-nodeX openstack user, can access this key. How does this magic happen in term of
10:24:41 nate rights, since our compute nodes do not have any admin role ?
10:31:32 nate Our compute nodes have the service role on the service project, as well as a custom admin-compute role that only has two extra policies in neutron
10:40:41 opendevreview Merged openstack/nova master: [CI]Make nova-tox-py312-threading voting https://review.opendev.org/c/openstack/nova/+/955791
11:41:11 gibi Uggla: re ceph volume creation gate issue. I filed https://bugs.launchpad.net/cinder/+bug/2121941
11:41:41 gibi it happens about 30% of the time
11:48:32 gibi Uggla: as the patch making the py312-threading job voting landed I marked https://blueprints.launchpad.net/nova/+spec/eventlet-removal-part-1 as implemented and opened https://blueprints.launchpad.net/nova/+spec/eventlet-removal-gazpacho as the continuation
12:03:23 sean-k-mooney nate: the comput and admin cannot access the key, we store it in libvirt using the enduser access when the vm is creatd
12:03:43 sean-k-mooney its the presence of the key as a libvirt secreate that allows it to work
12:04:33 sean-k-mooney so it was the user keystone token that granted access but we only have that whiel we are attachign the voluem or creating the vm based on there request
12:05:16 jkulik sean-k-mooney: would that key then get transported on live-migration to another node, too? does libvirt do that automatically or is there some special mechanism in Nova?
12:05:19 sean-k-mooney gibi: we debuged that cidner volume isseu a few weeks ago
12:05:40 sean-k-mooney jkulik: i belivw ew do not suprot live migration with encypted volumes today
12:05:57 jkulik ah. ok. I was assuming :)
12:06:18 sean-k-mooney jkulik: that was a limitation intially and we plan to solve it using the same stragey for vtpm mitragion when that is complete
12:06:54 gibi sean-k-mooney: it is the same? what is the solution? is there a bug I can duplicate mine to?
12:07:10 sean-k-mooney for vtpm migration we are introducing 2 other modes, deployment where the encyrption keey will be owned by nova not the end user and host where the secret will be copied form host to host by reading it form libvirt and creating it
12:07:56 sean-k-mooney gibi: no, i dough into it, found the error and looked at how cidner is implemtneding cpu trotteling breifly
12:08:19 sean-k-mooney i brought it up on the QA channel
12:08:44 sean-k-mooney but i think i found a bz for it
12:08:47 sean-k-mooney ill need to check back
12:09:10 jkulik very helpful. thank you. also found the spec for that: https://github.com/openstack/nova-specs/blob/master/specs/2025.2/approved/vtpm-live-migration.rst
12:09:13 sean-k-mooney there is a diffent bug in teh qemu we are suing on debian 12 that i think is already fixed
12:09:37 sean-k-mooney gibi: let me check the irc logs and see if i can find the details
12:10:29 opendevreview Balazs Gibizer proposed openstack/nova stable/2025.1: Reproduce that only half of the PCI devs are removed https://review.opendev.org/c/openstack/nova/+/959308
12:10:30 opendevreview Balazs Gibizer proposed openstack/nova stable/2025.1: Fix pci_tracker.save to delete all removed devs https://review.opendev.org/c/openstack/nova/+/959309
12:10:35 gibi sean-k-mooney: thanks
12:12:03 opendevreview Balazs Gibizer proposed openstack/nova stable/2024.2: Reproduce that only half of the PCI devs are removed https://review.opendev.org/c/openstack/nova/+/959310
12:12:04 opendevreview Balazs Gibizer proposed openstack/nova stable/2024.2: Fix pci_tracker.save to delete all removed devs https://review.opendev.org/c/openstack/nova/+/959311
12:13:02 sean-k-mooney gibi: https://meetings.opendev.org/irclogs/%23openstack-qa/%23openstack-qa.2025-08-12.log.html
12:13:10 sean-k-mooney so its https://bugzilla.redhat.com/show_bug.cgi?id=2336437
12:13:17 opendevreview Balazs Gibizer proposed openstack/nova stable/2024.1: Reproduce that only half of the PCI devs are removed https://review.opendev.org/c/openstack/nova/+/959313
12:13:18 opendevreview Balazs Gibizer proposed openstack/nova stable/2024.1: Fix pci_tracker.save to delete all removed devs https://review.opendev.org/c/openstack/nova/+/959314
12:13:26 sean-k-mooney gibi: oh right i stated trying to fix it
12:13:47 sean-k-mooney so i put this on hold due to the security bug then FF
12:14:01 sean-k-mooney gibi: teh fix i starteed on is using a newer qemu form the backports repo
12:14:24 sean-k-mooney there are 2 ways to do that i was trying the one clark suggested althouth the other way is simpler
12:15:29 sean-k-mooney the fixed qemu is avaibel in debian 12 backporta dn proably debian 13 so we can jsut swap the job to 13 on master after RC1 once we clean up the devstack patch for debian 13, so that will be a month or so away
12:15:30 gibi ack. I added the bz to the cinder bug
12:16:27 sean-k-mooney for stable if we use qemu form the backprots repo it "should" fix it but we will need to either use -t to enabel the backports repo when isntalling qemu or update the name of the package to include /backprots or wahtever
12:16:48 sean-k-mooney the latter is the harder approch i was trying but then i need to list all the package however it would be cleaner in the long rung
12:17:10 sean-k-mooney the former is eaiser to do but it requires use to supprot that in the package_install comamnd
12:17:24 sean-k-mooney which is doable jsut need some extra pluming to make it happen
12:18:01 gibi I see
12:18:41 gibi I will use the bug I filed on cinder as the target of rechecks but feel free to re-target that bug from cinder to whathever we use to track package issues
12:20:08 nate sean-k-mooney: Thanks for the clarification. But how does nova create the secret in libvirt. How does it access the secret stored in barbican ? You mentioned end-user access token. How is it passed to nova-compute ?
12:20:12 sean-k-mooney looks like i did a dumb and deleted my psi vm for debian 12 with the patch i have not pushed yet but i didn tget that far anyway
12:21:16 sean-k-mooney nate: yes so wehn a use attaches an encypted volume or creates a vm with it the pass a keystoen token, nova uses that token to access barbican and retrive the key and store it in libvirt
12:21:37 sean-k-mooney nate: but we only have that token in memory while we are processign teh api request form the user
12:21:51 sean-k-mooney so its discarded and nova does nto have access beyond that intial point
12:22:12 sean-k-mooney gibi: ill at this to my list to work on again next week
12:23:39 nate sean-k-mooney: Ok so nova running on the compute node get this token and use it to retrieve the encryption key ? Am I correct ?
12:24:10 nate sean-k-mooney: because I have a call to barbicanclient in the logs of nova on my compute node
12:24:27 sean-k-mooney yes
12:24:52 sean-k-mooney nova uses the toke supplied by the user to talk to other service like glance to get the image or barbican to get the secret
12:25:12 sean-k-mooney nova itself does nto have the ablity to retirive the barbica seccret with the creditals in the nova.conf
12:25:39 sean-k-mooney but the users token does adn like all service we are expected to use the users token where possibel to talk to other service when processing a users request
12:26:02 sean-k-mooney that why a user can take the action but an admin cannot
12:29:00 nate sean-k-mooney: Perfect great ! Thank you that clarifies it.
12:30:08 sean-k-mooney gibi: just for contenxt this is the call that either need to be done with -t backports https://github.com/openstack/devstack/blob/master/lib/nova_plugins/functions-libvirt#L72 or we need to move thos packages to here with /backports and # dist:debian12
12:31:58 sean-k-mooney i tired claks suggestion and while i could get it to work having to specyify all the deps one by one is more fagile IMO then doign it the other way so i think im goign to try the -t approch isntead next time.
12:32:40 sean-k-mooney gibi: basiclly i would have to list all the same packages you did in yoru downgrade patch for qemu-img and thats a pain
12:33:52 sean-k-mooney addin a branch to install_libvirt for debian 12 i think its just simpler the refactoing the install to use files
12:51:27 Uggla gibi thanks for the above info.
12:53:06 Uggla the msg from qemu-img is quite strange.
13:11:58 opendevreview Tobias Urdin proposed openstack/nova master: Retry more volume API functions on server error https://review.opendev.org/c/openstack/nova/+/942981
14:02:22 ratailor sean-k-mooney, gibi could you please review https://review.opendev.org/c/openstack/nova/+/946733 and https://review.opendev.org/c/openstack/nova/+/954460
14:03:43 opendevreview Rajesh Tailor proposed openstack/nova master: Fix typos https://review.opendev.org/c/openstack/nova/+/959322
14:06:28 ratailor Uggla, could you please review this clean backport to stable/2024.1 https://review.opendev.org/c/openstack/nova/+/952961
14:06:55 Uggla ratailor, sure I'm going to do it.
14:07:05 ratailor Uggla, Thanks!
14:12:50 gibi ratailor: https://review.opendev.org/c/openstack/nova/+/954460 is pretty featury so that probably need to wait G
14:14:16 gibi I'm +2 on https://review.opendev.org/c/openstack/nova/+/946733
14:14:22 ratailor gibi, ack. Thanks! could you please glance through it and check if anything is missing. when you have time.
14:22:25 sean-k-mooney ya i feel the same about 954460
14:22:39 sean-k-mooney we can revisit it after rc1 is cut in 8 days
14:22:47 sean-k-mooney so ping us again in like 2 weeks
14:23:46 sean-k-mooney https://review.opendev.org/c/openstack/nova/+/946733 is ok before RC1 but ill review it properly when i get back to my desk, grabing coffee
14:27:57 ratailor sean-k-mooney, sure. Thanks! I will do.
14:28:05 ratailor sean-k-mooney, should I resolve conflict here https://review.opendev.org/c/openstack/nova/+/957958 with your permission, looks like you backported directly from UI.
14:47:15 sean-k-mooney i did and i just have not had time to update it
14:47:25 bauzas gibi: sorry forgot the eventlet meeting, do we have it ?
14:47:51 sean-k-mooney i fyou want to rebase it properly feel free i was going to wait until i cleared my current backlog of patche befoer redoing it
14:48:12 sean-k-mooney that why i set - workflow on the patch orginally
14:48:32 sean-k-mooney i wanted to wait until after FF/RC was out of the way to finish the backport
15:00:36 opendevreview Rajesh Tailor proposed openstack/nova stable/2025.1: only show standard image properties in server show. https://review.opendev.org/c/openstack/nova/+/957958
15:28:33 zigo I'm having an issue with tempest's packaging: it's having tempest/cmd which conflicts with sytem's cmd.Cmd. Here's the build log:
15:28:33 zigo https://paste.opendev.org/show/bb1c8yKdZi4J7aKd4KsY/
15:28:33 zigo It's obviously failing when building the sphinx doc. Anyways, does anyone have a clue what I could do? (except a painful tempest.cmd folder rename)
15:38:54 clarkb is something doing from tempest import cmd? Otherwise they shouldn't conflict right?
15:40:46 clarkb hrm maybe it is part of the sphinx imports situation. Looks like your traceback has a whole import_module() routine that could be "polluting" things

Earlier   Later