| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-01-12 | |||
| 17:31:54 | sean-k-mooney | ok but i am not suggestign you woudl use qcow im suggestign you configre nova to use raw format but when we copy the raw file from the casche we woudl do that with --reflink so that there would nto be a data copy | |
| 17:32:29 | sean-k-mooney | so you woudl set https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.force_raw_images to true | |
| 17:32:31 | jayaanand | https://www.irccloud.com/pastebin/OCDzzgTM/ | |
| 17:32:47 | sean-k-mooney | and images-type=raw or images_type=flat | |
| 17:36:01 | jayaanand | ok, let me check if reflink will trigger clone at ONTAP | |
| 17:36:25 | jayaanand | i will explore and share my findings | |
| 17:36:30 | sean-k-mooney | ack | |
| 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 | |