| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-01-12 | |||
| 17:37:10 | sean-k-mooney | simply supproting a generic nfs feature like server side copies would be a much smaller chnage if that is suffeient to fullfile the usecase | |
| 17:38:52 | jayaanand | sure, we want to use RAW format to take advantage of propitiatory de-dupe, compression and COW | |
| 17:39:38 | jayaanand | and avoid double virtualization at storage layer and save VM cycles for QCOW2 maintenance | |
| 18:05:59 | opendevreview | sean mooney proposed openstack/nova master: Support os-vif TAP pre-creation for OVS/OVN ports https://review.opendev.org/c/openstack/nova/+/973149 | |
| 18:06:12 | opendevreview | sean mooney proposed openstack/os-vif master: Add TAP device pre-creation support for OVS/OVN https://review.opendev.org/c/openstack/os-vif/+/971231 | |
| 18:25:09 | opendevreview | sean mooney proposed openstack/nova master: Support os-vif TAP pre-creation for OVS/OVN ports https://review.opendev.org/c/openstack/nova/+/973149 | |
| #openstack-nova - 2026-01-13 | |||
| 02:39:56 | mkuroha | Hi gibi, sorry to bother you just after you got back from PTO. I’ve updated this patch based on your feedback. Please take a look and share any comments when you have time. https://review.opendev.org/c/openstack/nova/+/948304 | |
| 03:01:17 | seyeongkim | could someone please review this patch or give me any advices about the approch? thanks so much. https://review.opendev.org/c/openstack/nova/+/963665 | |
| 08:52:55 | gibi | sambork: o/ I'm not sure you saw gmaan's post merge comments on the conductor eventlet series. https://review.opendev.org/c/openstack/nova/+/962478 I think it worth checking if there are dead code / missing cleanup based on his comments in that patch | |
| 08:55:53 | sambork | hey gibi, thanks for pointing out this one! yeah I will check them ! | |
| 09:30:23 | bauzas | Uggla: fancy mentioning today as implementation review day ? :) | |
| 09:39:33 | Uggla | bauzas, you are right, I forgot about it yesterday. | |
| 09:40:18 | bauzas | Uggla: can I use https://etherpad.opendev.org/p/nova-2026.1-status as a base for reviewing patches | |
| 09:40:20 | bauzas | ? | |
| 09:43:05 | Uggla | bauzas, I still not updated it (gonna do it). So unfortunately not. But you can have a look at r_taken's https://blueprints.launchpad.net/nova/+spec/generalize-sev-code patch | |
| 09:43:16 | bauzas | thanks | |
| 09:43:41 | bauzas | and I also said to tkajinam that I was wanting to review his patches, tkajinam any first ones I should look at ? | |
| 09:47:17 | bauzas | Uggla: can you please set https://blueprints.launchpad.net/nova/+spec/generalize-sev-code to approved as we agreed at the PTG ? | |
| 09:54:07 | Uggla | bauzas, yep | |
| 11:04:27 | tkajinam | bauzas, all of my patches are in single chain so please start from https://review.opendev.org/c/openstack/nova/+/969263 (I triggered recheck because the failure in threading job looks unrelated (and has never seen before) | |
| 11:05:01 | tkajinam | the first one is the preparation work which extends the existing functional test coverage so I believe it's not very controversial :-) | |
| 13:45:34 | sean-k-mooney | seyeongkim: so that is a feature rather then a bug. its alos possibel to specify the boot order via teh block device mappings today | |
| 13:50:13 | sean-k-mooney | lookign at the bug report this does not seam to be a nova bug | |
| 13:50:27 | sean-k-mooney | the behvario depend on ght grub config and grub config is out os scope of nova/openstack | |
| 13:51:13 | sean-k-mooney | in nova we also dont offically suprpot dual booting. | |
| 13:51:27 | sean-k-mooney | at lest not in multipel disks like this | |
| 13:52:08 | sean-k-mooney | we supprot a singel root disk(local or cidner volume) + additiaonl ephermal disks or cinder data volumes | |
| 13:52:31 | sean-k-mooney | the bug report state that if both device hav ea boot_index set then it works today | |
| 13:54:17 | sean-k-mooney | if you do not use cinder voluems for the non root disk that woudl also be lost on operations like shelve | |
| 16:25:22 | gibi | sean-k-mooney: fyi the py312-treading job error tkajinam mentioned above in https://review.opendev.org/c/openstack/nova/+/969263 is complaining to FairLockGuard. So you might have imediate context on that issue | |
| 16:25:26 | gibi | TypeError: Cannot enter FairLockGuard while it is already active. Create a new instance for nested usage or wait for the current context to exit. | |
| 16:25:30 | gibi | https://zuul.opendev.org/t/openstack/build/ee184acdd25a404d872dbd294af556d2 | |
| 16:44:19 | gmaan | gibi: sambork: more than dead code, my main concern is cleaning up the scatter-gather executer. we can discuss it in wed call. | |
| 16:49:23 | gibi | gmaan: OK. I haven't read your comments deep enough. Indeed it is better to discuss on the tomorrows call. | |
| 16:49:31 | gmaan | ++ | |
| 17:05:59 | sean-k-mooney | gibi: i can take a look. its possibel that we are leakign locks between tests althoguh im not entirly sure how that woudl happen in this case. | |
| 17:07:09 | sean-k-mooney | nova.tests.unit.test_utils.TestFairLockGuard.test_context_manager_shared_between_threads | |
| 17:07:39 | sean-k-mooney | ok os it sthe test case that is testign the cross treadh sharing which is something i explictly did not want to supprot | |
| 17:08:30 | sean-k-mooney | well i need to look at the test code to see what that is testing | |
| 17:09:25 | gibi | sean-k-mooney: thanks for looking. I'm still trying to catch up after my PTO | |
| 17:09:48 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/tests/unit/test_utils.py#L1893-L1917 ya it is | |
| 17:10:00 | sean-k-mooney | gibi: no wories did you enjoy the break | |
| 17:10:27 | sean-k-mooney | i have not tested that in threaded mode so ill run that in a loop and see if it repoduces locally | |
| 17:10:38 | gibi | there were parts I enjoyed very much :) | |
| 17:15:11 | sean-k-mooney | ok ya so that test is not stable | |
| 17:15:43 | sean-k-mooney | it cant work relyably because i expclity detect the case wehre we context switch betwen thread 1 and thread 2. https://github.com/openstack/nova/commit/22012360c40045ac1bf6dd0dc95aea3e15fed0cd#diff-d6d688e548906bcae5669480a03749c0a52f32634762e23adfbcd8de88b9d980R1236-R1240 | |
| 17:16:27 | sean-k-mooney | biscly the exectpiotn that is beign raised happens if the first worker thread enters the context manager while the other worker thread is also in the context manger | |
| 17:16:47 | sean-k-mooney | if the kernel runs them serially the test will pass | |
| 17:16:56 | sean-k-mooney | if it decied to interleave them it wont | |
| 17:17:44 | sean-k-mooney | we have 3 options. i can remove the raise which was orginally there to prevent this type of sharing | |
| 17:17:52 | sean-k-mooney | i can remove the test | |
| 17:18:09 | sean-k-mooney | or i can alter the test to prevent the interleving but that not very useful | |
| 17:18:49 | sean-k-mooney | since the interation of the patch where i added that raise i added a buch of addtion lockign to make it safe to share the lockgrarud between threads | |
| 17:19:37 | sean-k-mooney | so removing the raise is proably the correct thing to do and just make it a debug log or remove that if and the self._active varible entirly | |
| 17:21:00 | sean-k-mooney | that raise only exists to provide a singal to use that | |
| 17:21:03 | sean-k-mooney | thread1 = threading.Thread(target=worker, args=(1, lock_guard)) | |
| 17:21:13 | sean-k-mooney | thread2 = threading.Thread(target=worker, args=(2, lock_guard)) | |
| 17:21:25 | sean-k-mooney | is a programing logic error | |
| 17:22:01 | sean-k-mooney | with the extra lockign i have added that shoudl now be safe even if i dislike it so the extra protection is not required | |
| 17:22:07 | sean-k-mooney | any prefernce on how to fix it | |
| 17:23:05 | sean-k-mooney | we can just say the comments are enouch to discourge that useage and delete the check, we can add a debug log or i can remove the test. | |
| 17:23:06 | gibi | I don't know at the moment. Sorry. | |
| 17:23:19 | gibi | I need to get back to this | |
| 17:23:30 | sean-k-mooney | its fine ill create a quick patch to remvoe the raise and ill ask this quetion on the review | |
| 17:23:42 | sean-k-mooney | and you can leave feedback when you have time | |
| 17:24:02 | gibi | cool. Thanks! | |
| 17:24:59 | sean-k-mooney | was there a bug for this if not ill just do "Related-Bug: #2048837" to tie it to the orgianal bug fix | |
| 17:25:33 | sean-k-mooney | tkajinam: ^ | |
| 17:46:19 | opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Add capability to load loader and nvram from xml https://review.opendev.org/c/openstack/nova/+/969086 | |
| 18:17:04 | opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Add capability to load ssm feature from existing xml https://review.opendev.org/c/openstack/nova/+/969131 | |
| 22:59:25 | JayF | gibi: finally got back around to this post-holidays; no code change was needed and I have an explanation: https://review.opendev.org/c/openstack/nova/+/969321 | |
| #openstack-nova - 2026-01-14 | |||
| 05:23:29 | opendevreview | Merged openstack/nova master: Do not fork compute workers in native threading mode https://review.opendev.org/c/openstack/nova/+/965466 | |
| 07:17:41 | ralonsoh | gibi, hello! I've tested pyroute2 0.9.5 in a /requirements patch | |
| 07:17:43 | ralonsoh | https://review.opendev.org/c/openstack/requirements/+/973210 | |
| 07:18:17 | ralonsoh | do you mind if we bump to this version (latest) right now? If we detect any other issue with os-vif, we can revert it again | |
| 07:39:02 | ralonsoh | just for reference: https://zuul.opendev.org/t/openstack/buildset/1b150188643d435e8813c9d8be2ea184. I added nova-ceph-multistore and tempest-integrated-compute jobs | |
| 08:08:33 | opendevreview | Merged openstack/os-vif master: reno: Update master for unmaintained/2024.1 https://review.opendev.org/c/openstack/os-vif/+/965493 | |
| 10:21:16 | gokhan | Hi everyone, | |
| 10:21:16 | gokhan | We are currently running OpenStack Caracal and our security audit team has raised several critical concerns regarding VNC console access via nova-novncproxy. I would like to get your insights on the best practices or if there are any missing configurations on our side. | |
| 10:21:33 | gokhan | Lack of Session Timeout: Once a VNC connection is established, it remains open indefinitely (or for very long periods), which is seen as a major risk if a workstation is left unattended. | |
| 10:21:51 | gokhan | Missing Rate Limiting: There is no built-in mechanism to limit the number of console URLs a single user can request in a short period, potentially leading to resource exhaustion or brute-force attempts | |
| 10:22:10 | gokhan | URL Hijacking Risk: If a console URL is intercepted, it allows immediate access to the VM without further authentication. | |
| 10:23:35 | gokhan | we are planning to implement: Setting [console] enforce_session_timeout = True and adjusting [consoleauth] token_ttl to enforce a hard disconnect (e.g., after 30-60 minutes), Implementing rate limiting at the HAProxy level using stick-tables based on source IP for the /remote-consoles endpoint, Removing none from auth_schemes to enforce vencrypt only. | |
| 10:24:25 | gokhan | Does enforce_session_timeout in Caracal fully address the "infinite session" issue by terminating the WebSocket proxy connection on the server side once the TTL expires? | |
| 10:24:34 | gokhan | Are there any known side effects of setting a very low token_ttl (e.g., 30s) while enforce_session_timeout is active? | |
| 10:25:06 | gokhan | Regarding the password authentication spec, what is the current stability status for KVM/Libvirt in Caracal? https://specs.openstack.org/openstack/nova-specs/specs/wallaby/approved/nova-support-webvnc-with-password-authentication.html | |
| 10:25:45 | gokhan | I would appreciate any guidance or best practices from the you, thanks :) | |
| 10:30:10 | gibi | gokhan: about vnc timeout we have https://specs.openstack.org/openstack/nova-specs/specs/2024.1/implemented/enforce-remote-console-session-timeout.html | |
| 10:35:15 | gibi | > Does enforce_session_timeout in Caracal fully address the "infinite session" issue by terminating the WebSocket proxy connection on the server side once the TTL expires? | |
| 10:35:20 | gibi | I believe so | |
| 10:35:37 | gibi | > Are there any known side effects of setting a very low token_ttl (e.g., 30s) while enforce_session_timeout is active? | |
| 10:37:21 | gibi | as far as I understand that would mean that the VNC session would disconnect after 30secs, if that is OK for you as a user experience then it is fine from nova perspective to configure such short ttl | |
| 10:40:55 | gibi | regarding password auth, it was never implemented. I think the last attempt was https://review.opendev.org/c/openstack/nova/+/622336 | |
| 10:42:08 | gibi | it had an approved spec so I think the nova core team was OK with that feature proposal. So if you are interested it can be revived. | |
| 10:43:53 | gibi | if you are new to openstack then here are our contributor guide https://docs.openstack.org/nova/latest/contributor/index.html | |
| 10:48:37 | gibi | JayF: +2+A thanks for the explanation | |
| 10:56:58 | gokhan | Regarding the password authentication; it’s a bit disappointing that it wasn’t fully implemented, but knowing its current status helps us explain the situation to our security audit team. We will evaluate the possibility of developing and reviving this feature with our team. | |
| 10:56:58 | gokhan | Thanks a lot for the clarification, Gibi! | |
| 10:56:58 | gokhan | It is very helpful to know that enforce_session_timeout is the server-side solution we were looking for. We now understand that token_ttl serves as both the link validity period and the maximum session duration when this feature is enabled. We will set a reasonable TTL (like 3600s) to balance security and user experience. | |
| 10:58:46 | gibi | ralonsoh: re pyroute2 0.9.5 the job you run actaully shows the same error about the event loop https://zuul.opendev.org/t/openstack/build/9e54327cbaa94a4b8ecf9c5472934c97/log/controller/logs/screen-n-cpu.txt#48564-48581 | |