Thursday, 2026-08-13

opendevreviewGhanshyam Maan proposed openstack/nova master: Unify the thread pool executors into a central factory  https://review.opendev.org/c/openstack/nova/+/99857104:01
opendevreviewGhanshyam Maan proposed openstack/nova master: Shutdown thread pool executors during service shutdown  https://review.opendev.org/c/openstack/nova/+/100021104:22
opendevreviewGhanshyam Maan proposed openstack/nova master: Shutdown thread pool executors during graceful shutdown  https://review.opendev.org/c/openstack/nova/+/100021105:07
opendevreviewGhanshyam Maan proposed openstack/nova master: Add doc and release notes for the graceful shutdown task tracking  https://review.opendev.org/c/openstack/nova/+/99714105:07
opendevreviewAnton Iacobaeus proposed openstack/nova master: libvirt: Generalize memory encryption config  https://review.opendev.org/c/openstack/nova/+/99846607:25
opendevreviewAnton Iacobaeus proposed openstack/nova master: libvirt: Add memory encryption config for TDX  https://review.opendev.org/c/openstack/nova/+/99860807:25
opendevreviewAnton Iacobaeus proposed openstack/nova master: libvirt: Launch security Intel TDX  https://review.opendev.org/c/openstack/nova/+/99924907:25
opendevreviewAnton Iacobaeus proposed openstack/nova master: doc: Add documentation for Intel TDX  https://review.opendev.org/c/openstack/nova/+/100008107:25
opendevreviewAnton Iacobaeus proposed openstack/nova master: libvirt: reject_mem_enc_instances  https://review.opendev.org/c/openstack/nova/+/100008207:25
opendevreviewAnton Iacobaeus proposed openstack/nova master: libvirt: Add os_firmware_secure  https://review.opendev.org/c/openstack/nova/+/100047207:25
opendevreviewAnton Iacobaeus proposed openstack/nova master: libvirt: Check only x86_64 arch for Intel TDX  https://review.opendev.org/c/openstack/nova/+/100080507:57
opendevreviewLajos Katona proposed openstack/nova master: libvirt: Add test for MTU overwrite during live migration  https://review.opendev.org/c/openstack/nova/+/99580308:33
opendevreviewLajos Katona proposed openstack/nova master: libvirt: Avoid setting MTU during live migration if different  https://review.opendev.org/c/openstack/nova/+/99580908:33
opendevreviewLajos Katona proposed openstack/nova master: Add regression test to repoduce bug 1854844  https://review.opendev.org/c/openstack/nova/+/99177208:33
opendevreviewLajos Katona proposed openstack/nova master: libvirt: Preserve queue_size during live migration  https://review.opendev.org/c/openstack/nova/+/99584108:33
RomanHros[m]Hello, please someone look at the https://launchpad.net/bugs/2016173. It looks like very beneficial patch but seems to be forgotten...08:38
fricklermelwitt: sean-k-mooney[m]: ^^ any reason this is stuck except lack of focus? https://review.opendev.org/c/openstack/nova/+/88039909:42
sean-k-mooney[m]nothing comes to mind09:45
sean-k-mooney[m]im still waking up but i can take a look properly when im at my desk09:48
opendevreviewStephen Finucane proposed openstack/nova master: trivial: Fix outstanding flake8 issues  https://review.opendev.org/c/openstack/nova/+/99971410:39
opendevreviewStephen Finucane proposed openstack/nova master: Add ruff-check  https://review.opendev.org/c/openstack/nova/+/97444110:39
opendevreviewStephen Finucane proposed openstack/nova master: Enable G (flake8-logging-format) rules  https://review.opendev.org/c/openstack/nova/+/99855710:39
gibiantia: tkajinam: after pulling down the latest version of the TDX series to the same machine I used before for testing I libvirt rejects the VM boot with 13:24
gibiAug 13 16:23:40 beast01.rhos.lab.eng.brq2.redhat.com nova-compute[1108220]: ERROR nova.compute.manager [instance: e034aa57-fdca-4ea2-831f-41bcf51eb1d3] libvirt.libvirtError: operation failed: Unable to find 'efi' firmware that is compatible with the current configuration13:24
gibiso I guess this is connected to the secure loader / secure firmware change13:25
antiagibi: okay interesting 13:25
gibiit is on centos 10 stream13:25
antiawhat firmware files does it have?13:27
gibihttps://paste.openstack.org/show/bT6yOXgAEr7XuYjlHCvI/13:27
gibithis is the xml13:27
antiathat forces no secure boot, does it have a no secure boot TDX firmware?13:28
gibicollecting...13:28
gibihttps://paste.openstack.org/show/bSKoS2kOht69y2yUygFX/13:29
gibithese are the descriptors13:29
gibiit seems that I have only one tdx descriptor and that points to a secureboot firmware13:30
antiayup that makes sense, I have the same on my system13:30
gibiOK so I guess I can boot if I request secureboot as well13:31
antiaor set it to 'optional'13:31
sean-k-mooneyoptinal effectivly mean off13:31
gibiI have OVMF.inteltdx.secboot.fd and OVMF.inteltdx.fd so I can also create a new descriptor13:32
sean-k-mooneyit means libvirt decies which migh tactully work now13:32
sean-k-mooneybeofre it used ot more or less be off but worht a try 13:32
antiaI think in this case libvirt has no other choice than to give an enabled one, but I could be wrong 13:32
gibisean-k-mooney: given I have only firmware descriptor for tdx + secure boot libvirt will select that if optional13:32
gibiI will test it :)13:32
antiaI created a no secure boot firmware from my available firmware 13:33
antiahttps://paste.openstack.org/show/bdbleKLLworBpma70kXB/13:33
antiaI suppose it works differently on centos13:34
gibiyepp optional works and the VM uses the secure boot firmware13:36
gibias that is the only one with tdx now13:36
gibiI will try antia's nosb descriptor now :)13:36
antia:D 13:37
gibi...adapted to my env13:39
sean-k-mooneyya its likely just a packaging issue13:40
sean-k-mooneythats not a blocker for the feature13:41
gibiyeah it seems to work 13:42
gibiso I'm OK too13:42
sean-k-mooneythat will get fixed in a future ovmf version eventually13:43
sean-k-mooneywe could add a note or just recommen using optional13:44
sean-k-mooneyi.e. in the feature release note13:44
sean-k-mooneyor docs13:44
gibiyepp13:44
antiayes can add that to docs13:45
sean-k-mooneyit would be nice to have a tmepest test for this eventually by the way , in whitebox or main tempest but since we cant run it upstream i would not proritze that before FF13:46
gibiyeah we discussed that in case of SNP and TDX as an optional step to provide whitebox coverage 13:46
sean-k-mooneywe just need to creat the flavor/image with the approate metadata to enabel the feature and spawn13:47
gibiI think both tkajinam for SNP and antia for TDX said they will try to add it13:47
gibiyepp that is and in whitebox we can look at the xml created13:47
sean-k-mooneytrue13:47
sean-k-mooneywhile we do not have the ablity to report upstream form our downstrema host we do have the ablity to runa  devstack job there in thory 13:48
sean-k-mooneyso may be we can figoure out a way to do that testing later13:48
sean-k-mooneyevertually we might eb able to make that public but we would have to sanitze the logs13:48
sean-k-mooneythat the mian blocker currenlty if its a post merge ci13:49
sean-k-mooneyi.e. a weekly perodic13:49
gibiI noted the os_secure_boot=optional thing in the doc patch in the TDX series13:50
opendevreviewKamil Sambor proposed openstack/nova master: Replace StaticallyDelayingWrapper with futurist DelayingExecutor  https://review.opendev.org/c/openstack/nova/+/99741013:55
gibiOK I'm cool with the TDX series now. I run some local tests as well with the latest series. 13:56
gibi/run/ran/13:57
opendevreviewAnton Iacobaeus proposed openstack/nova master: doc: Add documentation for Intel TDX  https://review.opendev.org/c/openstack/nova/+/100008114:29
opendevreviewAnton Iacobaeus proposed openstack/nova master: libvirt: reject_mem_enc_instances  https://review.opendev.org/c/openstack/nova/+/100008214:29
opendevreviewAnton Iacobaeus proposed openstack/nova master: libvirt: Add os_firmware_secure  https://review.opendev.org/c/openstack/nova/+/100047214:29
opendevreviewAnton Iacobaeus proposed openstack/nova master: libvirt: Check only x86_64 arch for Intel TDX  https://review.opendev.org/c/openstack/nova/+/100080514:29
dansmithunit tests are giving me "no such option enforce_scope in group [oslo_policy]" errors on several.. gmaan that was a recent change right? tried rebuilding venv, etc but still get it.. what am I missing?15:32
gmaandansmith: yes, this option is removed. i think recreate venv should fix it but is it nova giving error?15:34
gmaanmost of projects are fixed with this but not all. nova/placement etc are fixed alreadt15:34
dansmithyeah, venv rebuild seemed to not.. I figured it was a library version thing15:39
dansmithhrm15:40
dansmithgmaan: is it a version of oslo.policy I need to have or something?15:41
gmaandansmith: oslo.policy 6.0.0 removed it but nova should not be using it anywhere so it should work any version of oslo.policy15:42
dansmithgmaan: this is an example (one of many) https://paste.opendev.org/show/bdPguy48EU0zoQuirlrk/15:43
dansmithoslo.policy in the venv is indeed 6.0.015:44
gmaandansmith: ohk and nova seems old one not master https://github.com/openstack/nova/blob/master/nova/tests/unit/policies/base.py#L66-L7015:44
gmaanis it master and you updated the repo or stable branch?15:45
gmaanold nova with oslo.policy 6.0.0 will not work15:45
dansmithI'm on 3c23390cc815:45
dansmithwait a damn second15:45
dansmithlol, okay I did a local clone for a new working tree and I think it doesn't know what actual origin/master is so I'm based on something way old.. wtf15:46
gmaandansmith: yeah that's too old Jan 2615:47
dansmithyeah, stupid local shallow clone15:47
dansmithsorry for the noise15:47
gmaannp! I used to have same issue  in my multiple local copies and forgot to rebase before change and finds it during git review which adds more work. I tried to stick to have 1 or 2 local working repo now :)15:50
dansmithyeah I almost always work out of one repo, but for something destructive I'm using another.. I did a local clone and so it's (long stale) master branch becomes origin/master in the new clone so I thought I was rebased on master but wasn't15:52
dansmithwhich is stupid rookie mistake, I just rarely do this so I was on autopilot I guess15:52
gmaangibi: i updated the thread pool executor refactoring, i replied to this comment, I think there are more chance that different executors creation can happen in parallel compare to before this change where most of them were created during init https://review.opendev.org/c/openstack/nova/+/998571/comment/0f4554fd_8780afaf/17:04
gmaanthat is why I think a another lock is worth here to make them parallel but i do not have much performance data/impact so we can leave that with single lock (serial creation) and can change if any issue we see. let me know and i can update it accordingly 17:05
opendevreviewmelanie witt proposed openstack/nova master: Reproducer for bug 2016173  https://review.opendev.org/c/openstack/nova/+/94622218:18
opendevreviewmelanie witt proposed openstack/nova master: Call volume detach rollback API if detach fails  https://review.opendev.org/c/openstack/nova/+/88039918:18
opendevreviewGhanshyam Maan proposed openstack/nova master: Shutdown thread pool executors during graceful shutdown  https://review.opendev.org/c/openstack/nova/+/100021119:40
opendevreviewGhanshyam Maan proposed openstack/nova master: Add doc and release notes for the graceful shutdown task tracking  https://review.opendev.org/c/openstack/nova/+/99714119:55
gmaanmelwitt: i saw you +w on the 2nd change but this base change is also ready, just in case you missed it, but if you are still reviewing that, please ignore this ping :) https://review.opendev.org/c/openstack/nova/+/996299/20:03
melwittgmaan: yes, sorry I am mid review still. thanks for checking :)20:04
gmaanmelwitt: ohk, thanks20:04
gmaandansmith: there are other two changes are also ready to complete the graceful shutdown series, https://review.opendev.org/c/openstack/nova/+/1000211 and doc/releasenotes on top of it.  20:08
gmaandansmith: Those are dependent on thread pool executor refactoring which makes the executors shudown easy to handle during graceful shutdown, you are welcome to review the same but just to clarify that it is part of eventlet-removal and not directly to graceful shutdown BP https://review.opendev.org/c/openstack/nova/+/99857120:09
gmaanthat is why i set the different topic for those even they are in same series 20:10
dansmithgmaan: yeah I thought gibi had a -1 on the next patch.. is that resolved?20:10
gmaandansmith: I updated it but gibi have not checked the updated one yet20:11
gmaani resolved his feedback except one which i replied and waiting for him to check before we need any update there20:11
dansmithack20:18
melwittseems like the nova-graceful-shutdown job fails intermittently "Timed out waiting for compute service on npb4f32edc7a464 to be inactive (current: failed)" https://zuul.opendev.org/t/openstack/build/065f1dfcb6604871b71c9b7f84392275 but I don't see any gate-failure bugs open about it21:37
gmaanmelwitt: i have one but that is race between some test stopping service and other need it but this looks new to me, checking21:39
gmaanit seems two issue here 1. graceful shutdown is timeout andit seems lot of periodic tasks were running, this is solved in task tracking system where we stop running any new periodic tasks during shutdown22:03
gmaan2, when timeout it seems privsep-helper still running 22:04
gmaan Aug 13 19:11:12.515025 npb4f32edc7a464 nova-compute[92418]: INFO oslo_service.backend._threading.service [None req-e086152e-d33a-491b-8053-3d300bc9a11e None None] Graceful shutdown timeout exceeded, instantaneous exiting22:04
gmaanAug 13 19:11:12.543995 npb4f32edc7a464 systemd[1]: devstack@n-cpu.service: Main process exited, code=exited, status=1/FAILURE22:04
gmaanAug 13 19:11:12.544060 npb4f32edc7a464 systemd[1]: devstack@n-cpu.service: Failed with result 'exit-code'.22:04
gmaanAug 13 19:11:12.544388 npb4f32edc7a464 systemd[1]: devstack@n-cpu.service: Unit process 93426 (privsep-helper) remains running after unit stopped.22:04
gmaanAug 13 19:11:12.544562 npb4f32edc7a464 systemd[1]: devstack@n-cpu.service: Unit process 94748 (privsep-helper) remains running after unit stopped.22:04
gmaanAug 13 19:11:12.545602 npb4f32edc7a464 systemd[1]: devstack@n-cpu.service: Consumed 12.751s CPU time, 277.1M memory peak, 0B memory swap peak.22:04
gmaanthis seems something new22:04
gmaanthats does not seems the issue, i can see "Unit process 82937 (privsep-helper) remains running after unit stopped." in successful case also22:06
gmaannot sure why service status is updated in DB, because after 180 sec of graceful shutdown, test wait for another 180 sec timeout for serviec to be inactive22:11
gmaani see, I think its the status update interval time report_interval and  service_down_time  is racing with test timeout.  report_interval                = 120 service_down_time              = 72022:17
gmaanhttps://zuul.opendev.org/t/openstack/build/065f1dfcb6604871b71c9b7f84392275/log/controller/logs/screen-n-cpu.txt#101-11522:17
gmaani think i need to update the test script to consider the report_interval and service_down_time  for service status update timeout22:17
gmaanmelwitt: reported the bug, I will propose fix sometime tomorrow otherwise next week https://bugs.launchpad.net/nova/+bug/216344822:28
melwittthanks for doing that gmaan 22:44

Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!