| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-01-12 | |||
| 17:21:52 | sean-k-mooney | what im saying is it may be possible to not add a new backend at all | |
| 17:22:08 | sean-k-mooney | and simple use the more efficnet copy method when tis supproted by the file systems | |
| 17:22:11 | jayaanand | we won't introduce new format. we will user RAW with ONTAP copy on write capabilities | |
| 17:22:55 | jayaanand | we will delegate any clone operation to ONTAP for quick VM creation | |
| 17:23:00 | jayaanand | on top of RAW | |
| 17:23:35 | jayaanand | these are NFS files at ONTAP on top of FlexGroup | |
| 17:24:01 | sean-k-mooney | right the feedback im providieng is im not sure that we will accpate a vendor speciics storage backend in nova | |
| 17:24:18 | sean-k-mooney | and im tryign to understand if we can achive the same thing by jsut doing "cp --reflink=always source.raw destination.raw" | |
| 17:24:31 | MaxLamprecht[m] | Interestingly I heard yesterday also about the nfs4.2 native server-side-copy/file-cloning feature. Sadly ONTAP 9.16 currently returns NFS4 error not supported. I guess it‘s not implemented by netapp or hidden by some config flag or so. | |
| 17:24:32 | sean-k-mooney | when doign the copy fo the image | |
| 17:25:11 | sean-k-mooney | well nfs v3 supprot is deprecated in general | |
| 17:25:23 | sean-k-mooney | we ahve recommend 4.2 or a bove for many years now | |
| 17:25:46 | sean-k-mooney | that recomendation orgianlly came form the qemu storage maintaienrs | |
| 17:25:58 | jayaanand | docs.netapp.com/us-en/ontap/nfs-admin/ontap-support-nfsv42-concept.html | |
| 17:26:01 | sean-k-mooney | i.e. to move to v4+ due to lockign issues | |
| 17:26:28 | jayaanand | Max, almost all of our customers on NFS 4+ | |
| 17:26:39 | jayaanand | you can look into your specific issue | |
| 17:26:58 | MaxLamprecht[m] | Yes we also use nfs4.2 :) | |
| 17:27:44 | jayaanand | we tried "if we can achive the same thing by jsut doing "cp --reflink=always source.raw destination.raw""... this is introducing conversion overhead at ONTAP | |
| 17:27:54 | sean-k-mooney | http://nfsv4bat.org/Documents/ConnectAThon/2010/ss-copy-spec.pdf that netaps presetion on the feature form 2010 | |
| 17:28:24 | sean-k-mooney | but maybe it never got enabeld or is behind a config flag | |
| 17:30:10 | jayaanand | For direct storage on the ONTAP backend, QCOW2 images are automatically converted to the raw format | |
| 17:31:03 | jayaanand | https://www.netapp.com/media/10720-tr-4067.pdf | |
| 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 | |